I believe this is a recent regression.

Ctrl+k Ctrl+e are also broken Push log: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d96afcb35853&tochange=f5c29147aa66 Regressed by: Bug 947854

[Tracking Requested - why for this release]:

I was able to repro this on Firefox 40.0a2 (2015-06-23) build. Adding a tracking flag.

This patch looks like a workaround for a deeper issue. What change exactly caused this bug?

I won't see this as a workaround. We might eventually solve all of these things via CSS (with :focus-within, which we don't currently support), but changing the status first shouldn't be a bad idea anyway. The inner reason is that, mouse tracker check the position immediately, and if that check succeeds, it calls hideNavToolbar directly. So this bug might be due to the change of where the collapsed flag is set and checked in {show,hide}NavToolbar.

(In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #6) > I won't see this as a workaround. We might eventually solve all of these > things via CSS (with :focus-within, which we don't currently support), Let's worry about that when we actually want to do that. > The inner reason is that, mouse tracker check the position immediately, and > if that check succeeds, it calls hideNavToolbar directly. So this bug might > be due to the change of where the collapsed flag is set and checked in > {show,hide}NavToolbar. Can we fix that?

(In reply to Dão Gottwald [:dao] from comment #7) > (In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #6) > > I won't see this as a workaround. We might eventually solve all of these > > things via CSS (with :focus-within, which we don't currently support), > > Let's worry about that when we actually want to do that. Not now anyway. I've filed bug 1176997 for :focus-within but I don't think it would be fixed soonish. > > The inner reason is that, mouse tracker check the position immediately, and > > if that check succeeds, it calls hideNavToolbar directly. So this bug might > > be due to the change of where the collapsed flag is set and checked in > > {show,hide}NavToolbar. > > Can we fix that? I would rather see moving flag setting around as a workaround. But I guess we can do that. Not sure whether that would introduce new regression though. Alternatively, we can make mouse tracker call the callback asynchronously, but I'm not sure how dangerous it would be.

(In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #8) > > > The inner reason is that, mouse tracker check the position immediately, and > > > if that check succeeds, it calls hideNavToolbar directly. So this bug might > > > be due to the change of where the collapsed flag is set and checked in > > > {show,hide}NavToolbar. > > > > Can we fix that? > > I would rather see moving flag setting around as a workaround. But I guess > we can do that. Not sure whether that would introduce new regression though. We should restore pre-bug 947854 behavior here. That shouldn't introduce new regressions.

(In reply to Dão Gottwald [:dao] from comment #9) > We should restore pre-bug 947854 behavior here. That shouldn't introduce new > regressions. That could... but not sure anyway. Let's see.

Comment on attachment 8625808 [details] [diff] [review] another patch > // Track whether mouse is near the toolbox >- this._isChromeCollapsed = false; > if (trackMouse && !this.useLionFullScreen) { > let rect = gBrowser.mPanelContainer.getBoundingClientRect(); > this._mouseTargetRect = { > top: rect.top + 50, > bottom: rect.bottom, > left: rect.left, > right: rect.right > }; > MousePosTracker.addListener(this); > } >+ this._isChromeCollapsed = false; nit: please add a blank line before this._isChromeCollapsed = false;

Comment on attachment 8625808 [details] [diff] [review] another patch Approval Request Comment [Feature/regressing bug #]: bug 947854 [User impact if declined]: As the summary and comment 1 say [Describe test coverage new/current, TreeHerder]: n/a [Risks and why]: not clear [String/UUID change made/needed]: n/a

Comment on attachment 8625808 [details] [diff] [review] another patch Recent regression, taking it.

I have successfully reproduced the bug in Nightly 41.0a1 (2015-06-20) and windows 7 (32 bit) (Build ID: 20150620030209) Mozilla/5.0 (Windows NT 6.1; rv:41.0) Gecko/20100101 Firefox/41.0 Verified as fixed with latest aurora 41.0a2 (2015-06-29) (Build ID: 20150629134017) Mozilla/5.0 (Windows NT 6.1; rv:41.0) Gecko/20100101 Firefox/41.0

Successfully reproduce this bug on Nightly 41.0a1 (2015-06-20) (Build ID: 20150620030209) and Linux x64 Bug is now fixed on latest Aurora 41.0a2 (2015-06-30) Build ID: 20150630004006 Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0