Closed Bug 1165383 Opened 9 years ago Closed 9 years ago

Customize tab would not close when switch to Dev theme from Customize on Windows7 Basic/Classic theme

Categories

(Firefox :: Toolbars and Customization, defect)

Product:
Firefox
Component:
Toolbars and Customization
Version:
41 Branch
Platform:
Unspecified
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox39 --- unaffected

People

(Reporter: alice0775, Unassigned)

References

Details

(Keywords: regression) 

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

Steps To Reproduce:
1. Open Nightly41.0a1 with Newly created profile
2. Enter Customize mode
3. Click [Themes]
4. Click [Developer Edition]
5. Click [Exit Customize]

Actual Results:
Customize tab would not close.
Toolbar Pallets are disappears in the left side pane.
Click Close button of the Customize tab does nothing.
Switch tabs(click tabs/keypress Ctrl+tab/keypress ctrl+(number)) also does nothing.

Expected Results:
Customize tab should close.
Summary: Customize tab would not close when switch to Dev theme from Customize → Customize tab would not close when switch to Dev theme from Customize on Windows7 Classic theme
This problem may be only on Windows7 Basic and Classic.
Summary: Customize tab would not close when switch to Dev theme from Customize on Windows7 Classic theme → Customize tab would not close when switch to Dev theme from Customize on Windows7 Basic/Classic theme
Pushlog:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=ba9bb4a353b4&tochange=604006b08454

Suspect: 604006b08454	Brian Grinstead — Bug 1158872 - Remove white titlebar on Windows for Dev Edition theme;r=Gijs
Blocks: 1158872
Keywords: regression
After step5,
6. Close by clicking x button
7. Restart Nightly

Browser is completely invisible, though taskbar button exists.
OS: Unspecified → Windows 7
From my testing, I believe this problem is also fixed by the patch in Bug 1164952.  Here is a try build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ad8b9daf94b8.
Depends on: 1164952
(In reply to Brian Grinstead [:bgrins] from comment #4)
> From my testing, I believe this problem is also fixed by the patch in Bug
> 1164952.  Here is a try build:
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=ad8b9daf94b8.


The problem(comment#0) seems fixed with the try-build.

However, After restart, Browser has no border.
After switching window, border will come back.


If the title bar was also enabled in step 3.
After restart, Browser has no titlebar and no window control buttons.
In this case, switching window does not help.
Anyway
I think that 
the offending patch of bug 1158872 should be backed out from all tree.
(In reply to Alice0775 White from comment #6)
> Anyway
> I think that 
> the offending patch of bug 1158872 should be backed out from all tree.

Simply backing that out will cause the whole background to turn white again, but I think we could come up with a solution that removes that change and includes a different fix for that problem.  Working on a patch now.
(In reply to Brian Grinstead [:bgrins] from comment #7)
> (In reply to Alice0775 White from comment #6)
> > Anyway
> > I think that 
> > the offending patch of bug 1158872 should be backed out from all tree.
> 
> Simply backing that out will cause the whole background to turn white again,
> but I think we could come up with a solution that removes that change and
> includes a different fix for that problem.  Working on a patch now.

Here is an ongoing try push that does that: 

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0aa4dff36873
(In reply to Brian Grinstead [:bgrins] from comment #8)
> (In reply to Brian Grinstead [:bgrins] from comment #7)
> > (In reply to Alice0775 White from comment #6)
> > > Anyway
> > > I think that 
> > > the offending patch of bug 1158872 should be backed out from all tree.
> > 
> > Simply backing that out will cause the whole background to turn white again,
> > but I think we could come up with a solution that removes that change and
> > includes a different fix for that problem.  Working on a patch now.
> 
> Here is an ongoing try push that does that: 
> 
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=0aa4dff36873


Problem:
A. Enable Dev theme, then Press Alt key, Menu text is almost invisible.
   (Black text and Dark blue background)

B. Enable Dev theme, Toolbutton is not invert color in NavBar and MenuBar
   (Black button image and Dark blue background)

C. Enable Dev theme,  mouse on the topmost pixel row in fullscreen mode doesn't show the browser UI.

Problem A & B are solved if Titlebar enabled.
On https://treeherder.mozilla.org/#/jobs?repo=try&revision=af8bc1da4cef.

Problem:
A. mouse on the topmost pixel row in fullscreen mode doesn't show the browser UI.

B. Enable TitleBar, then Press Alt key, Menu text is almost invisible.
   (White text and White background)
In addtion to the Comment #0,

C. Switch to default theme. Theme returns to Dev theme after restart
In Basic style.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=0aa4dff36873
Problem
A. Enable Dev theme,  mouse on the topmost pixel row in fullscreen mode doesn't show the browser UI.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=af8bc1da4cef.
Problem:
A. mouse on the topmost pixel row in fullscreen mode doesn't show the browser UI.

B. Enable TitleBar, then Press Alt key, Menu text is almost invisible.
   (White text and White background)

C. Switch to default theme. Theme returns to Dev theme after restart
(In reply to Alice0775 White from comment #11)
> In addtion to the Comment #0,
> 
> C. Switch to default theme. Theme returns to Dev theme after restart

This is fixed in Bug 1164178, which just hasn't made it to the aurora build yet (I've requested uplift for this).
In Bug 1164178 it says that 41 is not affected, but here we have that 41 is affected, but ? on 40. Can we get verification this is fixed in both 40 and 41?
tracking-firefox40: ? → +
tracking-firefox41: ? → +
Brian, do you have plans to fix that in 40? Thanks
Flags: needinfo?(bgrinstead)
(In reply to Sylvestre Ledru [:sylvestre] PTO => July 10th from comment #15)
> Brian, do you have plans to fix that in 40? Thanks

I believe this problem was fixed by Bug 1164178, which is fixed in both 40 and 41.  If we can confirm that it's fixed we should be able to close this bug.  What flags do I need to set to request verification?
Flags: needinfo?(bgrinstead) → needinfo?(sledru)
Thanks. I did it for you (qe‑verify = +)
Flags: needinfo?(sledru) → qe-verify+
Florin, can somebody from QE verify that this bug is fixed? Please see comment 16 for more info. Thanks!
Flags: needinfo?(florin.mezei)
I tried this on FF41 (Dev edition) and I was not able to repro it. I am using win8.
This was already fix.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
status-firefox40: ? → ---
status-firefox41: affected → ---
tracking-firefox40: + → ---
tracking-firefox41: + → ---
Removing the needinfo request since Alice has confirmed this fix.
Flags: needinfo?(florin.mezei)
You need to log in before you can comment on or make changes to this bug.