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

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[arni2033]

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 3 (Or maybe Step 4. Or at least Step 5)

Please fix component if it's specified incorrectly.

Comment 1

[arni2033]

[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)

Comment 2

[:Gijs (he/him)]

Is this a regression? Does it work on Firefox 40, for instance?

Comment 3

[arni2033]

Yes, it's a regression. I can't reproduce this issue on Release 31, but it's presented on Release 40

Comment 4

[arni2033]

It starts from Release 35; Release 34 is not affected.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0e631971b841&tochange=0b81c10a9074

Too old for mozregression to bisect inbound builds. https://hg.mozilla.org/mozilla-central/rev/02566635767f looks like a solid candidate, though.

Comment 6

[(no longer active)]

Dao, can you take a look, please?

Comment 7

[Xidorn Quan [:xidorn] UTC+11]

Hmmm, it seems if the toolbar does not autohide when enters fullscreen mode, it would never hide afterward.

Comment 8

[Xidorn Quan [:xidorn] UTC+11]

Attachment: MozReview Request: Bug 1192683 - Retry hiding toolbox when some of safe-to-collapse conditions change.

Bug 1192683 - Retry hiding toolbox when some of safe-to-collapse conditions change.

Comment 9

[Xidorn Quan [:xidorn] UTC+11]

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...

Comment 10

[Ryan VanderMeulen [:RyanVM]]

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

Comment 11

[Ryan VanderMeulen [:RyanVM]]

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

Comment 12

[Pulsebot]

Backout:
https://hg.mozilla.org/integration/fx-team/rev/1362d2b7cdbd

Comment 13

[Xidorn Quan [:xidorn] UTC+11]

(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.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 15

[Xidorn Quan [:xidorn] UTC+11]

(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.

Comment 16

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/f944a86418a9

Comment 17

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f944a86418a9

Comment 18

[Nazir Ahmed Sabbir [:NaSb]]

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

Comment 19

[Md. Rahimul Islam]

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]