Closed
Bug 498100
Opened 15 years ago
Closed 15 years ago
Can not remove Toolbarbutton from menubar after Customize toolbars & uncheck Menubar.
Categories
(Toolkit :: Toolbars and Toolbar Customization, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.9.2a1
People
(Reporter: alice0775, Assigned: dao)
References
Details
Attachments
(1 file, 1 obsolete file)
3.79 KB,
patch
|
neil
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090612 Firefox/3.5.0 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090613 Minefield/3.6a1pre ID:20090613042114 Can not remove Toolbarbutton from menubar after Customize toolbars & uncheck Menubar. Reproducible: Always Steps to Reproduce: 1.Start Minefield with New profile 2.View > Toolbars > Menubar and set it to uncheck state. 3.View > Toolbars > Customize 4.Drag & drop "Print"button to the Menubar and Click done. 5.View > Toolbars > Menubar and set it to check state. 6.View > Toolbars > Customize 7.Drag & drop "Print"button to Customize Toolbar Window from the Menubar 3. Actual Results: Can not remove Expected Results: Can remove
Reporter | ||
Updated•15 years ago
|
Keywords: regression
Version: unspecified → Trunk
Assignee | ||
Comment 1•15 years ago
|
||
sigh, xbl.
Assignee: nobody → dao
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #383114 -
Flags: review?(neil)
Assignee | ||
Updated•15 years ago
|
Component: Toolbars → Toolbars and Toolbar Customization
Product: Firefox → Toolkit
QA Contact: toolbars → toolbars
Assignee | ||
Comment 2•15 years ago
|
||
Comment on attachment 383114 [details] [diff] [review] patch this breaks persisting, since it removes the attribute rather than setting it to "false"
Attachment #383114 -
Attachment is obsolete: true
Attachment #383114 -
Flags: review?(neil)
Assignee | ||
Comment 3•15 years ago
|
||
this should work, still need to test it
Assignee | ||
Updated•15 years ago
|
Attachment #383149 -
Flags: review?(neil)
Comment 4•15 years ago
|
||
Comment on attachment 383149 [details] [diff] [review] patch v2 This looks mostly good (and fixes DSS too, yay!) but one thing I don't understand is why you changed the currentSet getter...
Assignee | ||
Comment 5•15 years ago
|
||
(In reply to comment #4) > (From update of attachment 383149 [details] [diff] [review]) > This looks mostly good (and fixes DSS too, yay!) but one thing I don't > understand is why you changed the currentSet getter... For the same reason currentSetChanged is called in there: toolbar customization doesn't set the currentSet, but it modifies the toolbar content and lets toolbar.xml rebuild the currentSet (via the getter) in order to persist it.
Updated•15 years ago
|
Attachment #383149 -
Flags: review?(neil) → review+
Comment 6•15 years ago
|
||
Comment on attachment 383149 [details] [diff] [review] patch v2 Ah, that makes sense, thanks! > var node = this.firstChild; > var currentSet = ""; >+ var i = 0; > while (node) { > node = node.nextSibling; >+ i++; > } [I wonder why this wasn't ever written as a for loop]
Assignee | ||
Comment 7•15 years ago
|
||
If you prefer it more compact, I could offer this:
> for (let i = 0, node; node = this.childNodes.item(i); i++) {
Assignee | ||
Comment 8•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/eb2734e5956a
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Assignee | ||
Updated•15 years ago
|
Keywords: regression
Comment 9•15 years ago
|
||
(In reply to comment #7) > If you prefer it more compact, I could offer this: > > for (let i = 0, node; node = this.childNodes.item(i); i++) { That's an ingenious approach ;-)
Comment 10•15 years ago
|
||
Verified fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090706 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090706042748
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•