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)
Firefox
Toolbars and Customization
Tracking
()
NEW
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.
Comment 1•7 years ago
|
||
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
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•