1476259 - Malfunctions of overlay loader [meta]

Status: RESOLVED FIXED

(MailNews Core :: XUL Replacements, defect)

Description

[Jorg K (CEST = GMT+2)]

Attachment: Lightning double arrows.png

Let's start a bug to list malfunctions of the overlay loader with certain add-ons.

For Lightning, I see double-up arrows, as per the attachment.

ThunderHTMLedit doesn't work, nothing happens when you click the HTML tab. Geoff said: ... for some reason, the select event isn't firing when you click on them.

Comment 1

[Jorg K (CEST = GMT+2)]

Attachment: thunderHTMLedit-WE.zip

Comment 2

[Jorg K (CEST = GMT+2)]

I see
  Loading chrome://messenger/content/overlayBindings.css into chrome://messenger/content/newmailalert.xul

In the debug console. Why is that CSS file loaded into every XUL document?

Comment 3

[Jorg K (CEST = GMT+2)]

This also doesn't look right:
  JavaScript error: resource:///modules/Overlays.jsm, line 187: TypeError: sheet is undefined

Comment 4

[[:MakeMyDay]]

The arrow issue is not related to the overlay loader, it's a regression of the twisty fix(es). I filed bug 1476718 for it.

Comment 5

[[:MakeMyDay]]

Do you want to track the issues in this bug directly or better convert it into a meta bug?

Comment 6

[Jorg K (CEST = GMT+2)]

Looks like a meta-bug would be better, no?

Comment 7

[Helge Skjeveland]

I'm using self-updated TB 63.0 x64 (2018-5-23) Daily now, and the included Lightning 65.a1 works fine, except for one problem: If I close and re-start TB, the  Lightning icons on the menu bar have disappeared.  The AddOns Manager shows it installed, though.  In order to get the icons to re-appear for use of the add-on, I have to disable Lightning from TB's AddOns Manager, close TB, re-start it, and the Enable Lightning from the AddOns manager, whereupon TB says it has to re-start, and then the Lightning icons are there again. Since Lightning itself works fine now, is there a procedure I can use that will bring up TB with the Lightning menu-bar icons active? Can I help with testing this for a fix? Looks to me like TB is only partially actuating the add-on, not displaying it in the menu bar, on a fresh startup. Thank you.

Comment 8

[Magnus Melin [:mkmelin]]

Don't understand which version you're using. Daily is now 64.0a1 and there lightning buttons show up. For anything below, you may have to start with -purgecaches

Comment 9

[Martin Pecka]

I tried to convert an addon to use the XUL overlay according to the instructions at https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63 . The extension itself works, but I can't find a way to open the options page (before, I converted it to be compatible with TB 60). Is there a way to specify the options page in manifest.json if the options are still XUL-based? The manifest.json docs refer only to HTML options pages... 

The addon code for reference can be found here: https://github.com/peci1/more-snooze/tree/webextension .

Comment 10

[Geoff Lankow (:darktrojan)]

(In reply to Martin Pecka from comment #9)
> Is there a way to specify the options page in manifest.json if the options are still XUL-based?

No there isn't, but there should be. Filing a bug now.

Comment 11

[Onno Ekker [:nONoNonO UTC+1]]

Don't know if I should report this here, but it looks like the overlay loader doesn't handle the insertafter attribute the right way. According to https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/insertafter the first attribute found should be selected to insert the new id, but the overlay loader inserts it after the last attribute found.

Comment 12

[Jorg K (CEST = GMT+2)]

This should go into a new bug, but let's hear Geoff first.

Comment 13

[Geoff Lankow (:darktrojan)]

The code has the comment "Not breaking here to match original behavior", which contradicts the documentation. I'm not sure what the original behaviour was, but I agree with the documentation. Please file a bug, Onno.

Comment 14

[Dave Royal]

I think this is problem with the overlay loader.

I'm trying to convert this addon (it's not mine) to 63 or above (I got it working in 60). 
https://addons.thunderbird.net/en-us/thunderbird/addon/use-bcc-instead/

I'm trying it with 64.0b4 (I get more errors in 63). The code is here:
https://github.com/revad/use_bcc_instead_B

On install I get (4 times):
Error creating URI (invalid URL scheme?)         Overlays.jsm:481
loadScript  resource:///modules/Overlays.jsm:481:9
load  resource:///modules/Overlays.jsm:197:28
load  resource:///modules/Overlays.jsm:42:5
observe  chrome://messenger/content/parent/ext-legacy.js:138:11

Comment 15

[Geoff Lankow (:darktrojan)]

I strongly suspect it's because you aren't using the full address of scripts in your <script> tags. Please try it and file a bug blocking this one if I'm right.

Comment 16

[Dave Royal]

I posted a query on discourse.mozilla.org: XUL preferences window is missing its groupbox labels.

https://discourse.mozilla.org/t/legacy-overlay-addon-migration-missing-groupbox-labels-in-prefs-window/35020

No answer, so asking here: is this a fault in the legacy overlay loader?

Comment 17

[Richard Marti (:Paenglab)]

Dave, bug 1493844 removed the "caption" and "groupbox" bindings. Since then you need to change <groupbox><caption label="&size.label;"/> to <groupbox><caption>&size.label;</caption>. I haven't checked if the new notation is backward safe.

This has nothing to do with the overlay loader but wit the ongoing removal of XBL bindings we need to follow.

Comment 18

[Alex Eng]

I've been working on porting my legacy XUL add-on, Clippings for Thunderbird, to Thunderbird 65, closely following the migration guide [1]. I have added the manifest.json file. My add-on has two JavaScript XPCOM components, and there are XUL overlays defined for the following:

• chrome://messenger/content/messenger.xul
• chrome://messenger/content/messengercompose/messengercompose.xul
• chrome://messenger/content/messageWindow.xul

After installing the add-on, the XPCOM components aren't being registered, and the UI for my add-on is not showing up in the expected places: a button in the status bar in the main mail window and message editor, and a context menu item in the message editor.

The following messages appear in the error console when Thunderbird starts up:

Ignoring unrecognized chrome manifest directive "overlay". ...... chrome.manifest:3
Ignoring unrecognized chrome manifest directive "overlay". ...... chrome.manifest:5
Ignoring unrecognized chrome manifest directive "overlay". ...... chrome.manifest:7
Ignoring unrecognized chrome manifest directive "style". ........ chrome.manifest:31
Ignoring unrecognized chrome manifest directive "interfaces". ... chrome.manifest:75
Ignoring unrecognized chrome manifest directive "interfaces". ... chrome.manifest:77

This is occurring on Thunderbird 65.0b4 on macOS 10.13.6 High Sierra. This is also occurring on my PC with Windows 7 (32-bit); same version of Thunderbird installed.

I have also observed similar errors appearing in the error console when installing the latest beta versions of other add-ons: Compact Header and Signature Switch.

Is this an issue with the overlay loader? Are there additional requirements that add-on authors have to fulfill for the new overlay loader to function properly?

[1] https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63

Comment 19

[Dave Royal]

Alex: FWIW an addon I converted has those messages:
https://github.com/revad/use_bcc_instead_C/

It also outputs various 'type error' messages, described here:
https://github.com/revad/use_bcc_instead_C/issues/3

The addon works OK - at the moment.

Comment 20

[Geoff Lankow (:darktrojan)]

(In reply to Alex Eng from comment #18)

Ignoring unrecognized chrome manifest directive "overlay". ...... chrome.manifest:3
Ignoring unrecognized chrome manifest directive "style". ........ chrome.manifest:31

Overlays and styles are handled by our new overlay loader, but not the original one, which spits out these error messages.

Ignoring unrecognized chrome manifest directive "interfaces". ... chrome.manifest:75

This isn't a thing any more. You cannot register an XPT file. I'm not 100% sure what you're supposed to do here, I guess that depends on your code. At least in an extension you control all of your code and don't have to worry about outside code conforming to your requirements.

I can't really say a lot else without seeing your code. Send me an email if you don't want to post it here.

Comment 21

[Alex Eng]

My code can be found here: https://github.com/aecreations/clippings-tb/tree/branches/5.6%2B/src

To see the add-on in action, download the XPI from here and add it to Thunderbird 60.x: http://aecreations.sourceforge.net/clippings/install.php

Comment 22

[Geoff Lankow (:darktrojan)]

Okay, I had a brief look. What I would do is convert the service component to a javascript module, and the dictionary components looks very similar to a Map, so I'd replace it with one of those.

As I said, the .idl files are obsolete technology and can be removed, along with the interfaces lines in chrome.manifest.

Comment 23

[Joachim Herb]

Since a few days (12.04.2019), my addon Compactheader does not work in the automatic tests: https://travis-ci.org/jmozmoz/compactheader/jobs/492474963 using Thunderbird 67.0 daily

If I try to install the addon over the normal file dialog in Thunderbird 67.0 the following error message is shown in the console:

1550351561326	addons.webextension.<unknown>	ERROR	Loading extension 'null': Reading manifest: Error processing icons.32: SyntaxError: String "chrome://CompactHeader/skin/cohe-icon.png" must be a relative URL Log.jsm:679
    append resource://gre/modules/Log.jsm:679
    log resource://gre/modules/Log.jsm:360
    error resource://gre/modules/Log.jsm:368
    _logMessage resource://gre/modules/Extension.jsm:375
    logError resource://gre/modules/Extension.jsm:371
    packagingError resource://gre/modules/Extension.jsm:358
    manifestError resource://gre/modules/Extension.jsm:344
    parseManifest resource://gre/modules/Extension.jsm:648
    InterpretGeneratorResume self-hosted:1255
    next self-hosted:1210

If I remove the icon setting, the addon can be loaded and the tests work. So what is the correct syntax?

There is no explanation in the wiki: https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63
(by the way, I applied for an account for the wiki to add some changes some time ago, but the application was rejected.)

Comment 24

[Geoff Lankow (:darktrojan)]

You can't use a chrome URL there, use a path relative to the manifest.

Comment 25

[Alex Eng]

(In reply to Geoff Lankow (:darktrojan) from comment #22)

Thanks for the hint; I'm now able to get my extension to work, although the status bar toolbar button that should be added by my extension is missing in the main mail window and the message compose window.

My extension preferences dialog, which uses <prefwindow>, is messed up; screen shot attached. Errors appear in the error console when it is opened:

TypeError: document.loadOverlay is not a function ............ preferences.xml:752:13
TypeError: control.radioChildConstructed is not a function ... radio.xml:29:13

Could this also be an issue with the overlay loader?

Comment 26

[Alex Eng]

Attachment: clippings-tb-prefs.PNG

Comment 27

[Geoff Lankow (:darktrojan)]

Not so much the overlay loader, <prefwindow> isn't a thing any more. You probably should change to <dialog> and rework the UI into tabs. Also, a word of warning, <preference> is on the chopping block too. You could switch to using preferencesBindings.jsm like we're doing in bug 1527770 or go directly to the preferences service.

Comment 28

[Lorenz Froihofer]

After porting XNote++ to Thunderbird 68, some people reported that sometimes the toolbar button does not show up and if that is the case, it can not be added from to toolbar customization dialogue. Upon next restart, things might work again. Things are not predictable. After I received the output of the error console from an affected user and discovered that I still had a reference to stringbundleset/stringbundle in the xnote-overlay.xul, I removed it but this did not fix the problem. Unfortunately, the issue sometimes shows up and sometimes doesn't making it hard to reproduce for a fix. After reading again through the docs about converting to a MailExtension, I thought that it might as well be an issue with the XUL overlay loader. Should I create a defect for this connected to this bug or does anyone have another explanation?

Link to the add-on: https://addons.thunderbird.net/en-US/thunderbird/addon/xnotepp/ - Current version 2.3.1 is the one that still contains the stringbundleset/stringbundle, but an update without it can be provided if required.

Comment 29

[Jorg K (CEST = GMT+2)]

And the toolbar issue isn't bug 1584160 which will be fixed in TB 68.3? You can try it now since we have a pre-release build:
http://ftp.mozilla.org/pub/thunderbird/candidates/68.3.0-candidates/build1/

Comment 30

[Geoff Lankow (:darktrojan)]

I'm not sure if it would cause the problem you see but I notice your code uses the document.persist function which no longer exists. See https://developer.thunderbird.net/add-ons/tb68/changes#document-persist-id-attribute for what to do.

Comment 31

[Lorenz Froihofer]

Thanks for pointing to bug 1584160 - have forwarded this information to affected users as the issue is not reproducible for me. document.persist is fixed for next version, but is not the reason for the intermittent behaviour.

Comment 32

[Holger Lehmann]

Some users reported that the colour of tagged emails disappears when installing and enabling the Add-On "Teamworkx Thunderbird Integration for Jira": https://addons.thunderbird.net/en-US/thunderbird/addon/create-jira-issue/

I could limit the "when it appeared" to the Thunderbird 64.x
All versions older than 64.0 (as well as Seamonkey) had no problems. Opening an existing profile (with the add-on installed) to be used by TB 64.x immediately exposes the described behaviour. Re-opening the sane profile with TB 63.x again (while keeping the add-on installed) shows the correct colourful behaviour.

When enabling the "Tag" column in the message tree the selected tags show up properly.
When deinstalling/disabling the add-on from TB (>=64.x) then problem goes away and the colours are restored.

I checked our CSS for any possible leaks and found nothing. I even tested a version with changes CSS.

Cheers,
Holger

Comment 33

[Wayne Mery (:wsmwk)]

Are we expecting more issues?

Comment 34

[Jorg K (CEST = GMT+2)]

Not since the thing has been removed in TB 74.