Closed Bug 923971 Opened 11 years ago Closed 10 years ago

F10 doesn't work for step over

Categories

(DevTools :: Debugger, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 35

People

(Reporter: taras.mozilla, Assigned: hsteen)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [shortcuts])

Attachments

(1 file)

It displays some firefox menu instead
Priority: -- → P3
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.
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
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.
Same as Geoffrey D. : it happens on Windows 8.1 with Firefox 26.0
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?
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.
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
Whiteboard: [shortcuts]
First time using the javascript debugger on Windows and experienced the same problem.
Changing platforms to All to include Windows.
OS: Linux → All
Hardware: x86_64 → All
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 :(
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?
I can confirm this for current Nightly on Windows. 34.0a1 (2014-08-04)
I can try working on this bug, but need some pointers to go ahead.

Thanks,
Jayesh
@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.
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, 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!
(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?
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.
Summary: F10 doesn't work for StepOver → F10 doesn't work for step over
No - makes no difference. :(
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..
(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..)
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?
(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.
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 ;)
Attachment #8500530 - Flags: review?(enndeakin)
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+
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)
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?
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
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)
https://hg.mozilla.org/mozilla-central/rev/24fe4de37125
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
Depends on: 1101873
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?
(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)
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?
Hi Jens,
Thank you!
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!
Product: Firefox → DevTools
Blocks: 1565711
Blocks: 1565713
No longer blocks: 1565711
No longer blocks: 1565713
You need to log in before you can comment on or make changes to this bug.