nav-bar order rearranged and uncustomizable on latest UX nightly

RESOLVED FIXED in Firefox 28

Status

()

Firefox
Toolbars and Customization
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: mconley, Assigned: mconley)

Tracking

Trunk
Firefox 28
All
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

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.
Summary: Extend customization target across (almost) the entire nav-bar → nav-bar order rearranged and uncustomizable on latest UX nightly
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
Attachment #745161 - Flags: review?(jaws)
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.
Attachment #745161 - Flags: review?(jaws) → review+
Status: NEW → ASSIGNED
Windows builds are completely busted as well with unresponding scripts. It's also very hard to customize the navbar.
Created attachment 745218 [details] [diff] [review]
Patch v1.1 (r+'d by jaws)

Thanks Jared!
Attachment #745161 - Attachment is obsolete: true
Attachment #745218 - Flags: review+

Comment 7

5 years ago
I fixed this on my own by using the "Reset UX" button in Help -> Troubleshooting Information.
For the folks who don't want to reset, this should be fixed in tomorrow's UX nightly.

Comment 9

5 years ago
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.
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
Flags: needinfo?(sm.1975.smith)
Actually, Sean, I've filed a separate bug for this issue - bug 868993. Please follow along there.
Flags: needinfo?(sm.1975.smith)

Comment 12

4 years ago
https://hg.mozilla.org/mozilla-central/rev/54326f03d1ff
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-jamun][fixed-in-ux]
Target Milestone: --- → Firefox 28
You need to log in before you can comment on or make changes to this bug.