Closed
Bug 20519
Opened 25 years ago
Closed 25 years ago
[dogfood] key events getting through to editor key listener (symptom = control-v pastes text twice in HTML text controls)
Categories
(Core :: XUL, defect, P1)
Tracking
()
VERIFIED
FIXED
M13
People
(Reporter: buster, Assigned: mjudge)
References
Details
(Whiteboard: [PDT+] [12/15])
html text fields now have a xul controller.
so commands issued by keybinding code now get to the editor via the controller
on the html text field content node.
the editor also has a key listener with some hard-coded bindings, to be used
when the editor is embedded in a XUL-less environment.
in the case of control-v (paste), the key binding code is issuing the command,
but not eating the key event. so the editor key listener is getting the key
event, and 2 pastes happen.
hyatt says it should be a simple matter of the key binding code properly
consuming the key event if a command is dispatched.
this allows us to keep our hardcoded key binding in place as a default for
anyone to embed the editor without xul and still get basic operations.
Severity: normal → major
Priority: P3 → P2
Target Milestone: M12
I've set for M12 because I know this will come up as a usability issue. let me
know if there's anything I can do to help.
Updated•25 years ago
|
Assignee: saari → hyatt
Comment 2•25 years ago
|
||
I'll take this.
*** Bug 20602 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] 12/10 (fix will probably be in early next week)
Comment 5•25 years ago
|
||
Ok, I think I've got a way to get configurable key mappings without using
overlays... instead of using overlays, let's point to key binding files that
will get loaded and held by the XUL cache.
Then the key listener can look in those hardcoded files before it looks at the
key bindings in the main window. This will give you configurable keys.
*** Bug 20744 has been marked as a duplicate of this bug. ***
hyatt: I don't understand your comment on 12/2. did you add that comment to
the right bug?
*** Bug 20516 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Assignee: hyatt → saari
Status: ASSIGNED → NEW
Comment 10•25 years ago
|
||
Assigning to saari, who can help out mjudge. cc'ing waterson who can help.
The idea here.
(1) Add three XUL files to xpfe/global/resources/content
textcontrolkeys.xul
editorframekeys.xul
browserframekeys.xul
These can be overlays (even though they won't really be being overlaid), that
contain the key binds.
(2) Modify the key listener to ask the command dispatcher (accessible from the
XUL doc) for the current focused object. If it's an input field or textarea,
we'll look in textblah.xul. If it's a DOM window, then depending on whether or
not it's in edit mode, we'll use one of the other two files. mjudge can
probably tell how to query the shell to find out if it's in edit mode.
(3) After a profile is chosen, the three key bindings XUL files should be loaded
up (synchronously?) and put into the XUL cache. waterson can help with
explaining how to do this. They'd be in chrome://global/content/, but you want
to wait until a profile is determined to load them.
(4) The only tricky part. The key bind code needs to execute and bubble up/be
capturably by the relevant immediate parent. (e.g., the key event starts at the
input, textarea, or DOM window that's relevant). Make sure that you don't let
the master key bind table get involved (we don't want it being handled twice).
(5) Once this is in place, Ender can remove all hardcoded key bindings.
(6) We make Gecko ship with XUL and RDF (yeah, baby, yeah, baby, yeah!).
Comment 11•25 years ago
|
||
Also, in case I wasn't clear, if the file doesn't contain a key binding for the
relevant key event, then it SHOULD go to the master key table (if there is one).
Comment 12•25 years ago
|
||
One other point: another thing waterson can help out with...
The three files should only make full-fledged XUL docs once from the
prototypes... they should then be kept around so that we don't end up making
them over and over again.
Reporter | ||
Comment 13•25 years ago
|
||
*** Bug 20781 has been marked as a duplicate of this bug. ***
Summary: [dogfood] key events getting through to editor key listener → [dogfood] key events getting through to editor key listener (symptom = control-v pastes text twice in HTML text controls)
Reporter | ||
Comment 14•25 years ago
|
||
added the symptom to the summary to make it obvious what problem this bug
addresses from the user's point of view.
Comment 15•25 years ago
|
||
*** Bug 20995 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 16•25 years ago
|
||
Hyatt and myself landed all of this last night. Now, I don't know if editor has
removed their hard coded keybinds yet, but they can now. XPToolkit work is done
here.
Marking fixed because it makes me feel warm and fuzzy, but maybe this should go
back to editor guys
Reporter | ||
Comment 17•25 years ago
|
||
re-opening. I agree that XPToolkit's work is done, but the editor team still
needs to remove the hardcoded key bindings. assigning to myself.
Comment 18•25 years ago
|
||
Clearing FIXED resolution due to reopen.
Assignee: buster → saari
Severity: major → critical
Status: ASSIGNED → NEW
Reporter | ||
Comment 19•25 years ago
|
||
sending back to xptoolkit.
keystrokes simply aren't getting to text controls. I comment out the hardcoded
keybindings in the editor, and I get no keybinding action in the browser URL
bar, content area text controls, address book chrome, etc.
I'm using code pulled late 12/9.
Reporter | ||
Comment 20•25 years ago
|
||
a bit more data...
it seems that I do get the key binding commands in the browser url bar *the
first time the url bar gets focus* But if the url bar ever loses focus, it
never gets key events again. html controls never get key binding commands, nor
did the chrome in address book.
Comment 21•25 years ago
|
||
Did you write the keybindings? We didn't write them for you... you have to set
up your own keybindings in the URL bar and browser window....
I thought Mike Judge and Akkana were working on this...
Reporter | ||
Comment 22•25 years ago
|
||
hyatt: that must be it. I misunderstood, and thought that when saari checked
in, the editor keybindings were in as well. Re-assigning to mjudge.
Mike, when you get the editor keybindings checked in, be sure to remove the
hardcoded keybindings in the editor event listener. That part is trivial. If
you already have a bug on the editor key bindings, you can dupe this one to
that.
Updated•25 years ago
|
Whiteboard: [PDT+] 12/10 (fix will probably be in early next week) → [PDT+] [12/15]
Comment 23•25 years ago
|
||
updating fix by datte
Reporter | ||
Comment 24•25 years ago
|
||
*** Bug 21492 has been marked as a duplicate of this bug. ***
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 25•25 years ago
|
||
key binidngs are working now. ya!
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 26•25 years ago
|
||
VERIFIED 1999121508 builds.
Comment 27•25 years ago
|
||
Note, xulkey-V in the urlbar still pastes twice -- see bug 21602. I don't quite
understand what this bug was or why it wasn't a dup of that one, but the Summary
sounds a lot like 21602, that dom events aren't getting cancelled after XUL
keybindings act upon them and so are getting through to the editor event
listeners.
Reporter | ||
Comment 28•25 years ago
|
||
It sounds like there's some confusion about editor event listeners vs. html text
control frame event listeners.
The editor has it's own event listener, totally independent of whether it's
wrappend in an html text control frame. Any hardwired keybindings in this event
listener should be removed now that the keybinding stuff is in.
The html text control frame also has an event listener. This includes no key
bindings. It's used only to propogate events from the embedded webshell up to
any event listeners bound to the DOM content node <input type=text> or
<textarea>. Without this, things like <textarea
onKeyDown=doSomethingInJavascript()> won't work, because the events don't bubble
up from the embedded webshell (which holds the editor). In other words, events
don't bubble up past webshell boundaries without help.
Hope that helps.
Updated•25 years ago
|
Status: VERIFIED → REOPENED
Comment 29•25 years ago
|
||
So I made a mistake in verifying this. By my reading there's no way this could be fixed if
bug 21602 isn't. Based on buster's comments it would seem that's not the case however.
if someone could state a testcase that doesn't involve bug 21602 then I really appreciate
it and be glad to verify this bug properly. Reopening to clear the verified resolution.
Comment 30•25 years ago
|
||
Clearing FIXED resolution due to reopen.
Comment 31•25 years ago
|
||
final m12 candidates are spinnning now. moving to m13.
if we fall off track and need to respin m12 for some
yet unknown reason we can consider this if you get
a fix in hand.
Assignee | ||
Comment 32•25 years ago
|
||
honestly this is in. if its not in m12 then it is definately in m13 saari fixed
this. I will wait to make sure
Reporter | ||
Comment 33•25 years ago
|
||
mike, I believe this was taken onto the M12 branch. So you can mark it fixed,
and QA can verify against the branch and the tip if they like.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 34•25 years ago
|
||
yeah i will bite the bullet. this is fixed
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 35•25 years ago
|
||
marking VERIFIED, mostly based on comments and bug 21602
You need to log in
before you can comment on or make changes to this bug.
Description
•