Closed
Bug 923971
Opened 11 years ago
Closed 10 years ago
F10 doesn't work for step over
Categories
(DevTools :: Debugger, defect, P3)
DevTools
Debugger
Tracking
(Not tracked)
RESOLVED
FIXED
Firefox 35
People
(Reporter: taras.mozilla, Assigned: hsteen)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [shortcuts])
Attachments
(1 file)
3.36 KB,
patch
|
enndeakin
:
review+
|
Details | Diff | Splinter Review |
It displays some firefox menu instead
Updated•11 years ago
|
Priority: -- → P3
Comment 1•11 years ago
|
||
It seems that F10 focuses the menu bar on Gnome. Unity doesn't seem to have that problem, so the distro builds for Ubuntu should be OK, but Firebug seems to work in all cases, so there must be some way around that.
Comment 2•11 years ago
|
||
F10 is a common shortcut for GTK applications — see bug 376649.
While the the devtools perform the key binding in XUL [2], Firebug attaches listeners in JS [1] and set the addEventListener's `useCapture` to `true` [3]. I'm not sure if setting the `phase` attribute in the `key` element would make any difference or if it would cause any other side-effects.
I must mention that all of this makes the debugging experience a PITA under GTK environments.
[1] https://github.com/firebug/firebug/blob/07f278e8af05c0f219968431146ad953fadc144d/extension/content/firebug/chrome/chrome.js#L1249-L1268
[2] https://mxr.mozilla.org/mozilla-aurora/source/browser/devtools/debugger/debugger.xul#209
[3] https://github.com/firebug/firebug/blob/07f278e8af05c0f219968431146ad953fadc144d/extension/content/firebug/js/scriptPanel.js#L1651
Comment 3•11 years ago
|
||
I can report the exact same problem on windows (8) and Firefox 25.0.1. Trying to step over with F10 will show the firefox hidden menu (File Edit [...] Help) whatever the debugger have the focus or not.
Comment 4•11 years ago
|
||
Same as Geoffrey D. : it happens on Windows 8.1 with Firefox 26.0
Comment 5•11 years ago
|
||
I can confirm this for current Nightly on Windows. 29.0a1 (2014-01-13) *sadface*
I do have the same problem under Windows 7 Professional + Firefox 26.0
This makes debugging very hard. Any work round until this is fixed?
Comment 7•11 years ago
|
||
Yes, detach the debugger/toolbox into the external window - which doesn't have a menu and doesn't eat the F10 shortcut.
Thanks but I would like to know if there is a solution while keeping the debugger/toolbox attached.
Comment 9•11 years ago
|
||
You should be able to use Cmd + ' (single quote) however it seems to be broken in Nightly for me :(
http://dxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/browser/devtools/debugger.dtd#190
Filed bug 962665
Updated•11 years ago
|
Blocks: devtools-shortcuts
Whiteboard: [shortcuts]
Comment 12•11 years ago
|
||
First time using the javascript debugger on Windows and experienced the same problem.
Comment 13•11 years ago
|
||
Changing platforms to All to include Windows.
OS: Linux → All
Hardware: x86_64 → All
Comment 14•11 years ago
|
||
This popped up again on twitter: https://twitter.com/Venemo/status/488634194537754624
F10 is muscle memory for a lot of people trying out a new debugger :(
Comment 15•11 years ago
|
||
ALT already opens the firefox menu and the debugger is not only detached from the window, but also the page it leaves. probably by mistake and a bug?
Comment 16•11 years ago
|
||
I can confirm this for current Nightly on Windows. 34.0a1 (2014-08-04)
Comment 17•11 years ago
|
||
I can try working on this bug, but need some pointers to go ahead.
Thanks,
Jayesh
Comment 18•11 years ago
|
||
@Jayesh, what kind of pointers are you looking at?
The scenario for recreating the issue as follows:
1. Open a page with Javascript code.
2. Press F12 to bring up the Debugger
3. Put a debug point ing the Javascript and start debugging the Javascript code
4. The F11 button (Step into) works fine, but if you try to use F10 for step over, the Firefox menu becomes visible instead.
5. The step over is not performed.
Comment 19•11 years ago
|
||
Hi Kangkan,
Thanks for the update. Actually, I am looking pointers to solve the bug. Some guidance what source files I can debug for this.
Thanks,
Jayesh
Comment 20•10 years ago
|
||
Hi Jayesh, take a look at how Firebug deals with this from comment 2 and note that the step-over key is declared in XUL here (the actual key codes are defined in debugger.dtd):
http://dxr.mozilla.org/mozilla-central/source/browser/devtools/debugger/debugger.xul#238
If you need any further assistance, come find us in #devtools on IRC. Good luck!
Comment 21•10 years ago
|
||
(In reply to Jayesh from comment #19)
> Hi Kangkan,
>
> Thanks for the update. Actually, I am looking pointers to solve the bug.
> Some guidance what source files I can debug for this.
>
> Thanks,
> Jayesh
Hi Jayesh. This bug currently isn't assigned to you, but you expressed your interest in working on it a while ago. Are you still interested in working on it?
Assignee | ||
Comment 22•10 years ago
|
||
Builds are failing for me, no idea why - but I think these three minor changes *might* fix the bug:
debugger.xul : add "event" keyword to command
<command id="stepOverCommand"
oncommand="DebuggerView.Toolbar._onStepOverPressed(event)"/>
debugger-toolbar.js : add an 'e' argument:
_onStepOverPressed: function(e) {
and add inside the if-clause inside that function:
if(e && e.preventDefault){
e.preventDefault();
}
Untested.. and I need sleep, so I'm not waiting to see if another build succeeds tonight.
Updated•10 years ago
|
Summary: F10 doesn't work for StepOver → F10 doesn't work for step over
Updated•10 years ago
|
Blocks: dbg-frontend
Assignee | ||
Comment 23•10 years ago
|
||
No - makes no difference. :(
Assignee | ||
Comment 24•10 years ago
|
||
BTW: here's the stuff in core https://mxr.mozilla.org/mozilla-central/source/layout/xul/nsMenuBarListener.cpp#235
Assignee | ||
Comment 25•10 years ago
|
||
If I edit debugger-view.js and after this line in _initializePanes():
this._instrumentsPane.tabpanels.addEventListener("select", this._onTabSelect);
add this:
this._sourcesPane.ownerDocument.addEventListener('keydown', function(e){
if(e.keyCode===121){
DebuggerView.Toolbar._onStepOverPressed();
e.preventDefault();
}
}, true);
the problem is solved.
I have a feeling this is treating the symptom and not the cause though. In nsMenuBarListener.cpp, the relevant code is in nsMenuBarListener::KeyPress(nsIDOMEvent* aKeyEvent) and the first thing this method does is to check if the key press was already handled. Why isn't the key press already "handled" when it's defined by the <key> tag in debugger.xul? Why doesn't it make a difference if I call event.preventDefault() inside _onStepOverPressed()? Why does this work for, say, the F11 key (which succeeds in doing "Step into" rather than "Full screen" when the debugger has focus) but not for F10?
So I've found a fix, but I don't know if it's the right one..
Assignee | ||
Comment 26•10 years ago
|
||
(In reply to Hallvord R. M. Steen from comment #25)
> Why does this work for, say, the F11 key (which succeeds in doing "Step into"
(The short answer: because the menu bar listener code doesn't do anything for F11. It does get called, and the keypress is not considered "handled", but there's no specific action in this code for F11 so it doesn't get in the way..)
Comment 27•10 years ago
|
||
Both the menubar listener and key elements are attached as listeners to the same target document. Since the menubar listener is added first, its listener runs first.
You can fix this by switching nsMenuBarFrame to use AddSystemEventListener instead of AddEventListener, which would happen to fix this as a side effect, but is probably the right thing to anyway.
I didn't test it, but I assume that the step over key is only enabled or present while the debugger is open?
Assignee | ||
Comment 28•10 years ago
|
||
(In reply to Neil Deakin from comment #27)
> You can fix this by switching nsMenuBarFrame to use AddSystemEventListener
> instead of AddEventListener
I'll test this right away - many thanks! :-D
> I didn't test it, but I assume that the step over key is only enabled or
> present while the debugger is open?
Yes. AFAIK.
Assignee | ||
Comment 29•10 years ago
|
||
So - this seems to compile and work fine. I was struggling a bit with the mq patch stuff, so I hope I got it right.
My first ever C++ contribution ;)
Assignee | ||
Updated•10 years ago
|
Attachment #8500530 -
Flags: review?(enndeakin)
Comment 30•10 years ago
|
||
Comment on attachment 8500530 [details] [diff] [review]
devtools-F10-fix.patch
Looks ok. Did you test this on the try server?
Attachment #8500530 -
Flags: review?(enndeakin) → review+
Assignee | ||
Comment 31•10 years ago
|
||
No, I only built it locally. I haven't quite figured out how to do the try server testing yet (although I believe I have access)
Assignee | ||
Comment 32•10 years ago
|
||
I have no idea what options to use for the try server - could you push this change to the try server on my behalf or tell me what a sensible config is?
Assignee | ||
Comment 33•10 years ago
|
||
Tried this just to learn: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=dc1787ab27a3
Assignee | ||
Comment 34•10 years ago
|
||
Neil, does that look good to you? No failures on try server.
I think this is the point I'm supposed to add a checkin-needed keyword.
Flags: needinfo?(enndeakin)
Keywords: checkin-needed
Comment 35•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/24fe4de37125
Please add your email address to your hg commit information.
https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F
Assignee: nobody → hsteen
Keywords: checkin-needed
Comment 36•10 years ago
|
||
Did you only run some of the tests? Since it's already checked in, we can try it out and see if anything wrong happens.
Flags: needinfo?(enndeakin)
Comment 37•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
Comment 38•10 years ago
|
||
I have the same problem with Firefox 34.0.5 on Windows 7. Pressing F10 opens menu bar instead of performing a debugger 'Step' command.
How can I reopen this bug?
Assignee | ||
Comment 39•10 years ago
|
||
(In reply to Alexander Kozlovsky from comment #38)
> I have the same problem with Firefox 34.0.5 on Windows 7.
The fix should be arriving with Firefox 35 (AFAIK, there's a follow-up fix coming later in bug 1101873 but I don't think anything was backed out in the mean time)
Comment 40•8 years ago
|
||
Hi all,
I have the same problem with Firefox Developer Edition 52.0a2 (2016-11-30) (x86) on Windows 7.
The first press F10 opens menu bar and 'Step over' command of debugger then second press F10 only closes menu bar. And then these steps in loop.
Can we reopen this bug?
Comment 41•8 years ago
|
||
I reported this "upstream" at https://github.com/devtools-html/debugger.html/issues/1367
Comment 42•8 years ago
|
||
Hi Jens,
Thank you!
Comment 43•8 years ago
|
||
I am having this same problem with Firefox dev edition version 52.0a2 (2016-12-02) (64-bit) on Ubuntu using Gnome 3. WHen I am debugging JS files, pressing F10 opens the FF browser file menu. When I use older versions of FF (50 for example), it works fine in the same Ubuntu/Gnome 3 box. For whatever reason, everytime I hit F10 with Firefox dev edition 52.0a2, the file menu opens.
I like the new FF dev edition. I want to use it over Chrome.
Thanks for any help!
Updated•7 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•