The reason the key is in the binding is so that any user of <browser> gets that keystroke for free. Otherwise developers are most likely to forget it, yet it is an important keystroke for accessibility -- for example in help, view source, even in Chatzilla content. I have no problem with using a different strategy to implement F7 to solve the problems discussed in this bug, but we should continue to support it. Sun Microsystems, especially, uses this feature for their screen reader strategy. Some users need the key to be able to select text without need for a mouse.
Why not just role out a browser binding in the moz app that doesn't have the F7 handler?
(In reply to comment #2) > Why not just role out a browser binding in the moz app that doesn't have the F7 > handler? Unfortunately this isn't something we're able to do with our application at the moment. The (initial) goal is to be able to run it off a standard install of Firefox from a web server with no need to install extensions, etc. Who knows, our clients might even start using Firefox for general browsing, and some of them might want to use F7 :)
The proposal is not to remove this key, but to move it out of the binding. What I propose is: - move the key into one of the existing XUL keysets. - move the JS to browser.js or a more appropriate utility file if there is one. Aaron, would you consider a patch if I put one together?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Copying Ginn and Neil for feedback. Do you have any objections before I proceed with a patch to this key being moved out of the binding? My fix would likely be: - move the key to <keyset id="mainKeyset"> (browser-sets.inc) - Move the JS to browser.js
Assignee: aaronleventhal → brian
You should be able to make the browser binding respect preventDefault(): * Put the handler in the system event group (see bug 225563). * Check to see if preventDefault() was called on the event.
Created attachment 181269 [details] [diff] [review] Look for preventDefault Neil, you mean something like this (not tested yet)?
Attachment #181269 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 181269 [details] [diff] [review] Look for preventDefault That seems to work, although I'd prefer to see the !event.isTrusted after the || to avoid confusion over precedence.
Attachment #181269 - Flags: review?(neil.parkwaycc.co.uk) → review+
Oh, and r+sr too for the xpfe version tweaked as per my comment.
Created attachment 181281 [details] [diff] [review] Updated patch Order in conditional is reversed here as requested. Neil, if it's OK can you check it in please (I've tested), I don't have checkin rights.
Comment on attachment 181281 [details] [diff] [review] Updated patch You'll need approval, as the tree is currently frozen.
Attachment #181281 - Flags: review?(neil.parkwaycc.co.uk) → review+
Brian, when the tree is open, I can check it in for you if need be ...
What about Mozilla Suite? Are you going to fix it?
(In reply to comment #14) > What about Mozilla Suite? > Are you going to fix it? Good point. Updated patch coming ...
Created attachment 181524 [details] [diff] [review] Include Mozilla Suite binding Patch that now includes browser.xml of Mozilla Suite.
Comment on attachment 181524 [details] [diff] [review] Include Mozilla Suite binding r+sr=me
Attachment #181524 - Flags: review?(neil.parkwaycc.co.uk) → review+
I'd be grateful if any of you fine people could check this in once the tree is open again. Thanks!
Status: NEW → ASSIGNED
Seeking driver review for checkin to trunk.
Target Milestone: --- → Firefox1.1
Attachment #181524 - Flags: approval-aviary1.1a2?
Comment on attachment 181524 [details] [diff] [review] Include Mozilla Suite binding a=shaver
Attachment #181524 - Flags: approval-aviary1.1a2? → approval-aviary1.1a2+
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.