Closed Bug 1192683 Opened 4 years ago Closed 4 years ago

Firefox in fullscreen mode don't hide toolbars the first time the option "Hide toolbars" is checked (comment 1)

Categories

(Firefox :: Toolbars and Customization, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 44
Tracking Status
firefox40 --- wontfix
firefox41 --- wontfix
firefox42 --- affected
firefox43 --- affected
firefox44 --- verified
firefox-esr38 --- affected

People

(Reporter: arni2033, Assigned: xidorn)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

Summary: Firefox in fullscreen mode don't hide toolbar the first time the option is checked → Firefox in fullscreen mode don't hide toolbars the first time the option "Hide toolbars" is checked
[Correct Str, result, expectations]
STR:   (tested on Win7, Nightly 42.0a1 (2015-08-09))
1. browser.fullscreen.autohide -> false
2. Open new tab (Ctrl+T)
3. Enter fullscreen mode
4. Right-click the australis menu button, check "Hide toolbars"
5. Move mouse from navigator-toolbox
6. Click into content area

RESULT:
Nothing happens to the toolbars when I do steps 4-6

EXPECTATIONS:
Toolbars should hide after Step 4 (Or maybe Step 5. Or at least Step 6)
Summary: Firefox in fullscreen mode don't hide toolbars the first time the option "Hide toolbars" is checked → Firefox in fullscreen mode don't hide toolbars the first time the option "Hide toolbars" is checked (comment 1)
Is this a regression? Does it work on Firefox 40, for instance?
Flags: needinfo?(arni2033)
Yes, it's a regression. I can't reproduce this issue on Release 31, but it's presented on Release 40
Flags: needinfo?(arni2033)
It starts from Release 35; Release 34 is not affected.
Dao, can you take a look, please?
Blocks: 515196
Flags: needinfo?(dao)
Hmmm, it seems if the toolbar does not autohide when enters fullscreen mode, it would never hide afterward.
Blocks: 1208939
Bug 1192683 - Retry hiding toolbox when some of safe-to-collapse conditions change.
Attachment #8677901 - Flags: review?(dao)
This fix is trivial. So with this patch, there is one last case which would stop us from hiding the toolbar forever, which is that a textbox in chrome is focused when we enter fullscreen.

That would require a little more work to fix...
Flags: needinfo?(dao)
Attachment #8677901 - Flags: review?(dao) → review+
Attachment #8677901 - Flags: checkin?
Assignee: nobody → quanxunzhen
Comment on attachment 8677901 [details]
MozReview Request: Bug 1192683 - Retry hiding toolbox when some of safe-to-collapse conditions change.

https://hg.mozilla.org/integration/fx-team/rev/4169913a206b
Attachment #8677901 - Flags: checkin? → checkin+
Backed out for being the likely cause of OSX 10.10 mochitest-2 leaks (which the fullscreen tests happen to run in). Also, look at the Leaked URLs section of the full log.
http://archive.mozilla.org/pub/firefox/tinderbox-builds/fx-team-macosx64-debug/1445628213/fx-team_yosemite-debug_test-mochitest-2-bm106-tests1-macosx-build821.txt.gz
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #11)
> Backed out for being the likely cause of OSX 10.10 mochitest-2 leaks (which
> the fullscreen tests happen to run in). Also, look at the Leaked URLs
> section of the full log.
> http://archive.mozilla.org/pub/firefox/tinderbox-builds/fx-team-macosx64-
> debug/1445628213/fx-team_yosemite-debug_test-mochitest-2-bm106-tests1-macosx-
> build821.txt.gz

That's a rare intermittent, no? It seems to me except the one you mentioned here, all other m-2 jobs between the landing push and the backout worked fine. I don't think it is because of my patch.
Attachment #8677901 - Flags: checkin+ → checkin?
Yeah, you're right. Sorry for the confusion.

Also, for single-patch bugs like this (or bugs where all the patches are landing at the same time), please use the checkin-needed keyword. Automated bug marking tools can work better with them.
Keywords: checkin-needed
Attachment #8677901 - Flags: checkin?
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #14)
> Yeah, you're right. Sorry for the confusion.
> 
> Also, for single-patch bugs like this (or bugs where all the patches are
> landing at the same time), please use the checkin-needed keyword. Automated
> bug marking tools can work better with them.

Ah, okay, I forgot that keyword because I haven't been using that for a long time... Thanks for correction.
https://hg.mozilla.org/mozilla-central/rev/f944a86418a9
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 44
Reproduced this bug by following comment 0 on Linux, 64 Bit with Firefox Nightly 42.0a1 (2015-08-09)

This Bug is now verified as fixed on Latest Firefox Dev Edition 44.0a2 (2015-11-18)

Build ID 	20151118004041
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
QA Whiteboard: [bugday-20151118]
Depends on: 1226385
I have successfully reproduce this bug on firefox nightly 42.0a1 (2015-08-09)
with windows 8 (32 bit)
Mozilla/5.0 (Windows NT 6.3; rv:42.0) Gecko/20100101 Firefox/42.0

I found this fix on latest aurora 44.0a2 (2015-11-29)

Mozilla/5.0 (Windows NT 6.3; rv:44.0) Gecko/20100101 Firefox/44.0

Build ID : 20151129004009

[testday-20151127]
Status: RESOLVED → VERIFIED
Depends on: 1327948
Blocks: 1403878
You need to log in before you can comment on or make changes to this bug.