Open Bug 1327948 Opened 7 years ago Updated 2 years ago

In cases when toolbars should hide after hiding popup, they always hide with smooth transition

Categories

(Firefox :: Toolbars and Customization, defect)

defect

Tracking

()

People

(Reporter: arni2033, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
STR_1:
1. Click on content area (web page). Press F11 to switch to fullscreen
2. Move mouse to toolbars and to content area several times to make sure toolbars hide w/o transition
3. Hover mouse over Australis Menu button, then click it to open Australis Menu
4. Click on content area to close Australis Menu opened in Step 3


STR_2:
0. Open many tabs to cause overflow in tabs toolbar
1. Click on content area (web page). Press F11 to switch to fullscreen
2. Move mouse to toolbars and to content area several times to make sure toolbars hide w/o transition
3. Hover mouse over "all tabs" dropmarker in tabs toolbar, then click it to open "all tabs" popup menu
4. Click on content area to close "all tabs" popup menu opened in Step 3


STR_3:
1. Click on content area (web page). Press F11 to switch to fullscreen
2. Move mouse to toolbars and to content area several times to make sure toolbars hide w/o transition
3. Hover mouse over "New tab" toolbarbutton in tabs toolbar, then right-click it
4. Click on content area to close context menu opened in Step 3


AR:  Toolbars hide with smooth transition
ER:  Either X or Y (reporter believes only X is logical)
 X) Toolbars should hide without transition after Step 4 in each scenario
 Y) Toolbars should always hide with transition in Step 2 in each scenario (i.e. value "2". See below)

Note (some history with explanation):
 First of all, there was a pref "browser.fullscreen.animateUp" that defined the way toolbars hide when
 browser switches to fullscreen. Possible values were:
 0 - no transition, 1 - transition only the first time toolbars hide, 2 - always transition
 Currently only values 0 and 1 are allowed, and the pref was renamed to "browser.fullscreen.animate"
 Value "true"  of the new pref represents value "1" of the old pref;
 Value "false" of the new pref represents value "0" of the old pref.
 So regardless of how that pref is called now, the behavior defined by the pref should be respected.
No longer blocks: 1277113
Tested on Mac and Windows and I can reproduce it only on Windows. Tested on Nighlty 53.0a1(2016-01-10).
Component: Untriaged → Toolbars and Customization
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.