Closed Bug 1192683 Opened 9 years ago Closed 9 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)

Product:
Firefox
Component:
Toolbars and Customization
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 44
Tracking Flags:
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)

MozReview Request: Bug 1192683 - Retry hiding toolbox when some of safe-to-collapse conditions change.
(deleted), text/x-review-board-request
dao
: review+
Details
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.
status-firefox40: --- → affected
status-firefox41: --- → affected
status-firefox43: --- → affected
status-firefox-esr38: --- → affected
Keywords: regression
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: fx-fullscreen
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: 9 years ago
status-firefox44: affected → fixed
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.

Attachment

General

Creator:
Created:
Updated:
Size: