Make it possible to add widgets to the ends of customization areas

RESOLVED FIXED in Firefox 28



Toolbars and Customization
5 years ago
4 years ago


(Reporter: mconley, Assigned: mconley)


Firefox 28

Firefox Tracking Flags

(Not tracked)



(1 attachment, 2 obsolete attachments)

My patch for this bug focuses on making it possible to add widgets to the ends of customization areas, it also fixes the following:

1) Makes the nav-bar customization target not weirdly wide (with its flex="100") if the search bar is not in the panel by default
2) Makes it possible to add widgets to the nav-bar even if there were no widgets in there to begin with.

Patch coming in a second.
Created attachment 736024 [details] [diff] [review]
Patch v1
Assignee: nobody → mconley
Attachment #736024 - Flags: review?(jaws)
Comment on attachment 736024 [details] [diff] [review]
Patch v1

Review of attachment 736024 [details] [diff] [review]:

::: browser/base/content/browser.xul
@@ +659,5 @@
>                       label="&stopCmd.label;" removable="true"
>                       command="Browser:Stop"
>                       tooltiptext="&stopButton.tooltip;"/>
> +      <hbox id="nav-bar-customizationtarget" class="customization-target" flex="1"/>

As we talked about in person, I don't think the change from flex=100 to flex=1 will be good for addon-compat. We may need to find a different route to go here.
Attachment #736024 - Flags: review?(jaws) → review-
Created attachment 736066 [details] [diff] [review]
Patch v1.1

Alright, doing away with the flex="1" bit - we'll solve that problem down the road once we figure out what we're going to do with add-ons adding items to the toolbar.
Attachment #736024 - Attachment is obsolete: true
Attachment #736066 - Flags: review?(jaws)
Comment on attachment 736066 [details] [diff] [review]
Patch v1.1

Review of attachment 736066 [details] [diff] [review]:

::: browser/modules/CustomizableUI.jsm
@@ +1377,5 @@
> +    if (aElement.hasAttribute("flex")) {
> +      let parent = aElement.parentNode;
> +      let parentFlex = parent.hasAttribute("flex") ? parseInt(parent.getAttribute("flex"), 10) : 0;
> +      let elementFlex = parseInt(aElement.getAttribute("flex"), 10);
> +      parent.setAttribute("flex", parentFlex + elementFlex);

Negative flex or flex attributes that have non-numeric values are gonna make the behavior of this code somewhat undefined. In practice, I don't think add-ons with >10 users will have this type of issue, so I'm fine with leaving this as-is.

::: browser/themes/shared/
@@ +36,5 @@
>  }
> +#main-window[customizing] .customization-target {
> +  min-width: 100px;
> +  padding: 0 10px 0 10px;

Are we sure that we want to remove whatever vertical padding we had? Why not just use padding-left:10px; and padding-right:10px;? (besides the downside of the extra verbosity).
Attachment #736066 - Flags: review?(jaws) → review+
Created attachment 736443 [details] [diff] [review]
Patch v1.2 (r+'d by jaws)

Thanks - swapped out the padding rule for padding-left and padding-right.
Attachment #736066 - Attachment is obsolete: true
Attachment #736443 - Flags: review+
Landed in jamun as
Whiteboard: [fixed in jamun]
Landed in UX as
Whiteboard: [fixed in jamun] → [fixed in jamun][fixed in ux]
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.