868410 - nav-bar order rearranged and uncustomizable on latest UX nightly

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

This morning, I awoke to find my nav-bar on OSX completely re-orded and uncustomizable on the UX branch.

We believe this is caused by the patch in bug 864355, and we suspect it only affects OSX.

This is weird and unacceptable. I'll be investigating this today.

Cc'ing relevant members of the UX team to preempt influx of reports.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Ok, solved this one.

The super-special customizableui toolbar binding is being overridden by the global OSX skin[1] because there's some kind of special "nowindowdrag" attribute that only OSX knows about that we didn't take into account.

I've added an OSX-only entry to content/browser.css that takes precedence.

[1]: https://mxr.mozilla.org/mozilla-central/source/toolkit/themes/osx/global/global.css#24

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Attachment: Patch v1

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 745161 [details] [diff] [review]
Patch v1

Review of attachment 745161 [details] [diff] [review]:
-----------------------------------------------------------------

r=me granted that you fix the id selector below ;)

But it seems that this fix only works because it bumps up the selector specificity of this rule just enough to supersede the specificity of |toolbar:not([nowindowdrag="true"])|.

::: browser/base/content/browser.css
@@ +22,5 @@
> +  -moz-binding: url("chrome://browser/content/customizableui/toolbar.xml#toolbar-drag");
> +}
> +%endif
> +
> +toolbar-menubar[autohide="true"] {

This needs to be an id, not a tag name.

Comment 4

[u428464]

Windows builds are completely busted as well with unresponding scripts. It's also very hard to customize the navbar.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Attachment: Patch v1.1 (r+'d by jaws)

Thanks Jared!

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Landed on jamun as https://hg.mozilla.org/projects/jamun/rev/54326f03d1ff

Landed on UX as https://hg.mozilla.org/projects/ux/rev/54326f03d1ff

Comment 7

[Sean Smith]

I fixed this on my own by using the "Reset UX" button in Help -> Troubleshooting Information.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

For the folks who don't want to reset, this should be fixed in tomorrow's UX nightly.

Comment 9

[Sean Smith]

Had the chance to update another machine from last Friday's build to the one that was supposed to have this fix and the toolbar was again messed up and could not be reordered.

I was getting an unresponsive script warning that I had to stop because it kept looping back to the error message when I would try to let it continue.  After stopping it, UX finally opened a window with the screwy toolbar.

To save myself the hassle from doing another reset, I first tried removing my localstore.rdf file from my profile after closing and restarting UX, again having the unresponsive script warning, and could not reorder the toolbar or place items on it.

I then tried removing my prefs.js file with UX closed, and on restart, I did not get the script warning and the toolbar could be customized.  The normal ordering was present, I just had to add the couple of buttons I normally have on the toolbar and remove the ones I do not want.

The first machine with this problem is Win8 64-bit.  The other is a Win7 64-bit.

I still have the prefs.js file from the Win7 machine if it would be of benefit to anyone.  I don't know what kind of privacy concerns such a file would have, so I would rather email it to someone that can use it rather than attach it here, unless you can assuage my concerns.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Hey Sean,

Ouch, this sounds awful. :/

I'm interested in the following data:

1) The unresponsive script warning should tell you which file, and which line is causing the delay. Can you provide those?
2) The customization code stores the state of your toolbars in browser.uiCustomization.state. Can you either paste that information into this bug, or email it to me?

Thanks,

-Mike

Comment 11

[Mike Conley (:mconley) (:⚙️)]

Actually, Sean, I've filed a separate bug for this issue - bug 868993. Please follow along there.

Comment 12

[:Gijs (he/him)]

https://hg.mozilla.org/mozilla-central/rev/54326f03d1ff