250793 - make customizeToolbar.xul / .js import stylesheets

Status: RESOLVED FIXED

(Toolkit :: Toolbars and Toolbar Customization, defect)

Description

[Michiel van Leeuwen (email: mvl+moz@)]

toolkit/content/customizeToolbar.xul imports a css file from /browser. It needs
that style sheet in order to display the images on the buttons. But that makes
the xul file unusable for ather apps. The result is 3 copies in the tree so far.
And for sunbird, another one should be added. I don't want that.
If the stylesheets from the parent window would be imported using javascriptor
something, one copy would be enough.

Comment 1

[Michiel van Leeuwen (email: mvl+moz@)]

http://lxr.mozilla.org/seamonkey/source/calendar/sunbird/base/content/customizeToolbar.xul
now has code that tries do the import stylesheet work. So far, it seems to work.
It's only for sunbird ofcourse.

Comment 2

[Simon Paquet [:sipaq]]

*** Bug 255836 has been marked as a duplicate of this bug. ***

Comment 3

[basic]

Isn't it possible to fix this with dynamic stylesheet overlays
<http://xulplanet.com/tutorials/xultu/crosspov.html> ? Or am I missing something? 

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

From what i know, when using overlays you can only have one window with
customizable toolbars per app. The calendar extension for firefox won't be able
to have customizable toolbars. (correct me if i'm wrong)

Comment 5

[Simon Paquet [:sipaq]]

Looking at mozilla/browser/base/content/browser.css, the only style rule that
affects customizeToolbar.xul seems to be:

searchbar {
  -moz-binding: url("chrome://browser/content/search.xml#searchbar"); 
  
When I remove the reference to browser.css from customizeToolbar.xul the search
bar image does not show up in the Customize Toolbar dialog.

Instead of doing the whole stylesheet import mumbo jumbo, wouldn't it be
sufficient to just move the whole search xbl binding to toolkit. I could think
of some use cases for toolkit applications, that aren't browsers.

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

did you also remove the reference to chrome://browser/skin/?
The idea of the import is that it imports the styles for the buttons. Those
styles are needed to make the buttons show up in the dialog.

Comment 7

[Simon Paquet [:sipaq]]

(In reply to comment #6)
> did you also remove the reference to chrome://browser/skin/?

Nope. That problem would still have to be solved.

Comment 8

[Nickolay_Ponomarev]

It seems to me that we could just use 
  style chrome://.../customizeToolbar.xul chrome://app-specific-style1
  style chrome://.../customizeToolbar.xul chrome://app-specific-style2
  ...
in *.manifest files. See http://developer.mozilla.org/en/docs/Chrome_Registration#style

Comment 9

[Phil Ringnalda (:philor)]

Attachment: Fix v.1

I swear chrome.manifest uses Elfin Magic.

And yes, I'll file and take bugs for mail/ and calendar/, but I learned my lesson about needing too much review and having too few flags the last time around.

Comment 10

[Asaf Romano (gone)]

Comment on attachment 244171 [details] [diff] [review]
Fix v.1

r=mano

Comment 11

[Phil Ringnalda (:philor)]

browser/base/jar.mn 1.108
toolkit/content/customizeToolbar.xul 1.17