[Webkit-unassigned] [Bug 24025] New: access-keys conflict with rich text editing

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=24025

           Summary: access-keys conflict with rich text editing
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: hartman at videolan.org


I have found another issue with access-keys it seems.

This was originally found with the Wikipedia RichText editor WikEd. To
reproduce try a rich text textarea (either wikEd on Wikipedia or use
http://www.kevinroth.com/rte/demo.htm). Make sure the cursor is IN the
textarea. Note that the textarea responds to ctrl-alt-* now. TextEdit also
responds to these key combo's, so I'm guessing it's a left over from back then.

The problem. Text area keycombo's override HTML defined keycombo's (very
annoying if I want to save my edit on Wikipedia :D ). The second problem. They
actually work.. for instance ctrl-alt-p seems to insert a nice "data link
escape" character and ctrl-alt-s a "device control 3" character apparently. On
WikEd this eventually leads to a replacement character being saved. (one of the
JavaScript conversions apparently doesn't handle the char for some reason).
Anyways, this took me ages to figure out, and it seems counterintuitive and
also confusing.

This is the 3rd set of accesskey's that running into a conflict situation.
Perhaps a different approach is needed into solving this ? Perhaps something
like what Opera has ? At least then I have visual feedback as to when my
accesskey is working and when it is not. ~~~~


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.