WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
20476
Style Keys (Cmd+B/I) doesn't work within designMode=on HTML editor frame when main frame had text field focused - [WebHTMLView _handleStyleKeyEquivalent] bug
https://bugs.webkit.org/show_bug.cgi?id=20476
Summary
Style Keys (Cmd+B/I) doesn't work within designMode=on HTML editor frame when...
Adam Strzelecki
Reported
2008-08-21 05:58:17 PDT
See the URL or attached html file to reproduce the problem. This bug causes style keys like Cmd+B or Cmd+I not working in WordPress / TinyMCE or other Web based CMSes when we move from form input in main frame, to the designMode enabled HTML editor inner frame. ANALYSIS -------- 1. Both WebHTMLView frame objects (the main frame view and the inner designMode enabled frame view) receive - (BOOL)performKeyEquivalent:(NSEvent *)event on Cmd+B key but main frame view that had the input field focused before we moved to inner frame (designMode enabled), receive performKeyEquivalent first! (IMPORTANT) 2. It calls [self _handleStyleKeyEquivalent:event] then coreFrame->editor()->command(name) where name is "ToggleBold" 3. _hadleStyleKeyEquivalent calls -[WebHTMLView(WebPrivate) _canEdit] and it returns TRUE even the inner (designMode) frame view is currently active not the main frame view (called one) 4. Further on _handleStyleKeyEquivalent executes [self executeCoreCommandByName:"ToggleBold"] till it reaches: #0 WebCore::HTMLElement::isContentRichlyEditable (this=0x1511c9f0) at /Users/ono/Downloads/WebKit-
r35844
/WebCore/html/HTMLElement.cpp:627 #1 0x038420b4 in WebCore::isRichlyEditablePosition (p=@0xbfffecf8) at /Users/ono/Downloads/WebKit-
r35844
/WebCore/editing/htmlediting.cpp:177 #2 0x037b652f in WebCore::Selection::isContentRichlyEditable (this=0x68bbf20) at /Users/ono/Downloads/WebKit-
r35844
/WebCore/editing/Selection.cpp:514 #3 0x03372b59 in WebCore::SelectionController::isContentRichlyEditable (this=0x68bbf20) at SelectionController.h:50 #4 0x03375a75 in enabledInRichlyEditableText (frame=0x12d97770) at /Users/ono/Downloads/WebKit-
r35844
/WebCore/editing/EditorCommand.cpp:1041 #5 0x03375d4d in WebCore::Editor::Command::isEnabled (this=0xbfffedd4, triggeringEvent=0x0) at /Users/ono/Downloads/WebKit-
r35844
/WebCore/editing/EditorCommand.cpp:1388 #6 0x03375d78 in WebCore::Editor::Command::execute (this=0xbfffedd4, parameter=@0xbfffedd0, triggeringEvent=0x0) at /Users/ono/Downloads/WebKit-
r35844
/WebCore/editing/EditorCommand.cpp:1365 #7 0x001e8e17 in -[WebHTMLView executeCoreCommandByName:] (self=0x12f477d0, _cmd=0x2681e5, name=0x2650bd "ToggleBold") at /Users/ono/Downloads/WebKit-
r35844
/WebKit/mac/WebView/WebHTMLView.mm:2215 #8 0x001dcb02 in -[WebHTMLView _handleStyleKeyEquivalent:] (self=0x12f477d0, _cmd=0x268f3c, event=0x14d64f10) at /Users/ono/Downloads/WebKit-
r35844
/WebKit/mac/WebView/WebHTMLView.mm:3909 #9 0x001dcb9d in -[WebHTMLView performKeyEquivalent:] (self=0x12f477d0, _cmd=0x9033dac0, event=0x14d64f10) at /Users/ono/Downloads/WebKit-
r35844
/WebKit/mac/WebView/WebHTMLView.mm:3922 #10 0x93558e0e in -[NSControl _performKeyEquivalent:conditionally:] () #11 0x93558cda in -[NSView performKeyEquivalent:] () 7. Finally even when WebCore::HTMLElement::isContentRichlyEditable returns false after all, the [WebHTMLView _handleStyleKeyEquivalent] returns YES at: if ([string caseInsensitiveCompare:@"b"] == NSOrderedSame) { [self executeCoreCommandByName:"ToggleBold"]; return YES; } because it doesn't care about what executeCoreCommandByName returns 8. This causes performKeyEquivalent return YES too and making the performKeyEquivalent discarded for next event listener which is PROPER AND ACTIVE WebHTMLView of designMode='on' enabled frame of HTML editor SOLUTION -------- The solution is either - (BOOL)_canEdit should check if it is active frame or return FALSE otherwise OR _handleStyleKeyEquivalent should return YES only if the executeCoreCommandByName succeeds I've spent all yesterday trying to nail down this bug, I thought it is TinyMCE problem or Wordpress, but actually it is bug of Safari, ouch! I'd appreciate if you can fix this bug in both nightly WebKit and Mac OSX Apple releases, since this bug makes editing Wordpress pages in Safari real pain (I need to click somewhere on main frame out of text field) to make Cmd+B and Cmd+I keystrokes work. Best regards, and I hope my last night spent seeking this bug won't go down the drain.
Attachments
Testcase of this bug
(1.20 KB, text/html)
2008-08-21 06:01 PDT
,
Adam Strzelecki
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Adam Strzelecki
Comment 1
2008-08-21 06:01:54 PDT
Created
attachment 22919
[details]
Testcase of this bug Open it in Safari and follow instructions to reproduce the bug. Opera for Mac that has also Cmd+B/I keys enabled for HTML editor works fine here.
Robert Blaut
Comment 2
2008-12-27 13:19:14 PST
I can confirm this bug in the latest WebKit
r39474
.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug