Closed Bug 1430059 Opened 8 years ago Closed 8 years ago

Windows and tabs displayed via Tools > Add-on Options have lost formatting

Categories

(Thunderbird :: Add-Ons: General, enhancement)

Product:
Thunderbird
Component:
Add-Ons: General
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: jorgk-bmo, Unassigned)

Details

I have a few add-ons installed: LookOut (fix version) Lightning Calendar Tabs (modified to show options in tab) Shrunked Image Resizer Profile Switcher When opening the add-on options via the menu, the windows/tabs that open have lost all formatting. The panels are still working for "Header Tools Lite" and "Signature Switch". Note, where compatible versions aren't available, get them here: http://www.jorgk.com/misc/addons58/
Flags: needinfo?(richard.marti)
Flags: needinfo?(acelists)
This could be because the preferences bindings are no more in global but in messenger (bug 1424601). This was before in xul.css and automatically loaded for all XUL users. Now they have to load it itself. I think, I move this preferences bindings to bindings.css too. Then the extensions have only to load this one to get all needed bindings.
Flags: needinfo?(richard.marti)
I don't know if it would be possible to do something like this https://dxr.mozilla.org/comm-central/source/mozilla/layout/style/nsLayoutStylesheetCache.cpp#152 for the bindings.css.
Could we @import the bindings.css into messenger.css ?
Flags: needinfo?(acelists)
You can try it. But in content/messenger.css. But dialogs, prefs etc. don't need to use messenger.css and would still fail.
Assuming the tabs load messenger.css, which may not be true. The linked code only automatically loads xul.css for every document.
I tried the Compactheader and adding <?xml-stylesheet type="text/css" href="chrome://messenger/skin/preferences/preferences.css"?> to it's preferences.xul, fixed the issue. Jörg, can you test this with your extensions if this helps also?
We do ship xul.css as a standalone file (inside omni.ja). What about appending the bindings file to it as part of the build process? Then no changes in addons would be needed. Maybe Tom would know to do that.
Flags: needinfo?(mozilla)
(In reply to Richard Marti (:Paenglab) from comment #6) > I tried the Compactheader and adding > <?xml-stylesheet type="text/css" > href="chrome://messenger/skin/preferences/preferences.css"?> > to it's preferences.xul, fixed the issue. > Jörg, can you test this with your extensions if this helps also? Yes, I added this to "Lightning Calendar Tabs" and "LookOut (fix version)" and their options display became good again. "Header Tools Lite" was OK from the start, it has: <?xml-stylesheet href="chrome://communicator/skin/" type="text/css"?> <?xml-stylesheet href="chrome://messenger/skin/prefPanels.css" type="text/css"?> <?xml-stylesheet href="chrome://communicator/skin/pref/pref.css" type="text/css"?> however, I can't see that that's useful. prefPanels.css appears to be from suite/. "Profile switcher" is also OK, maybe my comment #0 was wrong. So should we close this bug and suggest that add-ons need to add <?xml-stylesheet type="text/css" href="chrome://messenger/skin/preferences/preferences.css"?>
Flags: needinfo?(richard.marti)
Flags: needinfo?(acelists)
If comment 7 would be possible, then we should do this which also would made it easier for us as we then don't need to add the bindings to every file that needs them. -> wait for Tom's answer.
Flags: needinfo?(richard.marti)
I'm not a friend of hacking the build system for this bug. Given that add-ons already need to change style chrome://messenger/content/customizeToolbar.xul ... they might as well add <?xml-stylesheet type="text/css" href="chrome://messenger/skin/preferences/preferences.css"?> if required, no?
It could also make our life easier if we could exchange the whole xul.css with our own. Then no overriding would be needed. But yeah, that would be a fork more.
(In reply to Jorg K (GMT+1) from comment #10) > I'm not a friend of hacking the build system for this bug. Given that > add-ons already need to change > style chrome://messenger/content/customizeToolbar.xul ... > they might as well add > <?xml-stylesheet type="text/css" > href="chrome://messenger/skin/preferences/preferences.css"?> > if required, no? No, because very few addons have a customizeToolbar, but the preferences dialog/tab change affects many. (In reply to Richard Marti (:Paenglab) from comment #11) > It could also make our life easier if we could exchange the whole xul.css > with our own. Then no overriding would be needed. But yeah, that would be a > fork more. Therefore I didn't propose a fork, but pick xul.css from m-c at build time and just append every file in c-c/common/bindings/*.css (where there would be links to the bindings in *.xml) to it. We would still get unforked xul.css from m-c with all future improvements. I assume addons using the statusbar are broken too now, did we give them advice to link in messenger.css (that sets up link to statusbar binding)?
Flags: needinfo?(acelists)
(In reply to :aceman from comment #12) > I assume addons using the statusbar are broken too now, did we give them > advice to link in messenger.css (that sets up link to statusbar binding)? I think not.
(In reply to :aceman from comment #12) > ... addons using the statusbar are broken too now ... Can you please add to the Wiki.
I would rather fix this globally and for all future bindings we adopt.
Neither fix nor traction here, so WONTFIX from me. Change documented here: https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_57#Changes_in_thunderbird59
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(mozilla)
Resolution: --- → WONTFIX
I don't like the proposed changes in addons. This will be an endless hunt for whatever XUL bindings we move to c-c addons will have to change the path. Maybe we could cheat in some cases and not change the path, e.g. it may be possible to keep chrome://global/content/customizeToolbar.xul instead of chrome://messenger/content/customizeToolbar.xul (notice we have some "chrome://communicator/..." paths). But globally if xul.css does no longer contain what it did and addons expect, they weill have to load some additional css that we provide. I'd really like to hear a real reason why we can't ship a modified xul.css (m-c's xul.css plus all the adopted css/bindings appended at the end).
Flags: needinfo?(mkmelin+mozilla)
We will be shipping TB 59 beta soon without any fix, so what is your solution for that?
Bug 1420229 adds a new file (components.css) we could try to override. This file is small and it would be loaded in all XUL files. But yes, this would be 60+.
My solution was comment 7, only that I can't implement it. Paenglab is in support too. Tom answered on IRC, that he does not think we should do it, but I don't find the reasons compelling. So if there is a decision on this it should be made properly and with real reasons. We already ship a XUL that is different from what Firefox ships (e.g. we have <statusbar> element, or <prefwindow> in this case) then why can't we ship a xul.css with the respective css and bindings that implement those elements? Even bug 1424601 only wired the moved pref elements for TB, SM is still busted.
I don't either find it too compelling to have a modified xul.css as such. But I think it isreasonable we put all such ports in a special file (and we do don't we? bindings.css), so there's only that one file add-ons need to import. Why not just require them to import that?
Flags: needinfo?(mkmelin+mozilla)
Component: General → Add-Ons: General
You need to log in before you can comment on or make changes to this bug.