Closed
Bug 868410
Opened 12 years ago
Closed 11 years ago
nav-bar order rearranged and uncustomizable on latest UX nightly
Categories
(Firefox :: Toolbars and Customization, defect)
Tracking
()
RESOLVED
FIXED
Firefox 28
People
(Reporter: mconley, Assigned: mconley)
References
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
mconley
:
review+
|
Details | Diff | Splinter Review |
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.
Updated•12 years ago
|
Summary: Extend customization target across (almost) the entire nav-bar → nav-bar order rearranged and uncustomizable on latest UX nightly
Assignee | ||
Comment 1•12 years ago
|
||
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
Assignee | ||
Comment 2•12 years ago
|
||
Assignee | ||
Updated•12 years ago
|
Attachment #745161 -
Flags: review?(jaws)
Comment 3•12 years ago
|
||
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+
Updated•12 years ago
|
Status: NEW → ASSIGNED
Windows builds are completely busted as well with unresponding scripts. It's also very hard to customize the navbar.
Assignee | ||
Comment 5•12 years ago
|
||
Thanks Jared!
Attachment #745161 -
Attachment is obsolete: true
Attachment #745218 -
Flags: review+
Assignee | ||
Comment 6•12 years ago
|
||
Landed on jamun as https://hg.mozilla.org/projects/jamun/rev/54326f03d1ff
Landed on UX as https://hg.mozilla.org/projects/ux/rev/54326f03d1ff
Whiteboard: [fixed-in-jamun][fixed-in-ux]
Comment 7•12 years ago
|
||
I fixed this on my own by using the "Reset UX" button in Help -> Troubleshooting Information.
Assignee | ||
Comment 8•12 years ago
|
||
For the folks who don't want to reset, this should be fixed in tomorrow's UX nightly.
Comment 9•12 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.
Assignee | ||
Comment 10•12 years ago
|
||
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)
Assignee | ||
Comment 11•12 years ago
|
||
Actually, Sean, I've filed a separate bug for this issue - bug 868993. Please follow along there.
Flags: needinfo?(sm.1975.smith)
Comment 12•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 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.
Description
•