Closed Bug 1061566 Opened 6 years ago Closed 5 years ago
Content of overlay'd wizardpage not shown
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 Build ID: 20140716183446 Steps to reproduce: I am modifying a wizard by adding a wizardpage through an overlay. The new wizardpage appears in the wizard as expected, however its content, i.e., its child nodes, do not appear. This was in action in an extension (ThunderBirthDay) modifying the calendar creation wizard of Lightning for several years now, and stopped working with Thunderbird 31. I triple checked everything from the overlay side, but can't find any mistake, so I am asking for help here. The attached XPI is a minimal "working" example of the bug (?): it registers an overlay with just a new wizard page for the calendar creation wizard of Lightning. In order to see the problem, perform the following steps: * install the attached XPI and Lightning * start creating a new calendar * choose to create it on your computer, click next * enter a name, click next * now you are on the new wizardpage Actual results: You can see on top of the wizardpage that the description and label attributes are taken into account. However the rest of the page is empty. In particular, the description node from the overlay is missing. Expected results: The overlay'd wizardpage contains a "description" node, whose content text should appear.
I did a few tests to narrow down the problem: Using Thunderbird 28 (with Lightning 2.6 and the attached file) works fine, updating to Thunderbird 29 (with the same version of Lightning and the attached file) does not. From my limited perspective, this looks like a bug in Thunderbird.
Component: Untriaged → General
This problem affects users of the new Provider for Google Calendar 1.0.1 extension too. When ThunderBirthDay extension is installed too they just get a blank screen in the calendar wizard. But without ThunderBirthDay extension the Provider for Google Calendar extension manages to modify the calendar wizard and adds new content. And this content is shown. Maybe you could work together and exchange information how the calendar wizard is modified by the extensions and why it works for one but not the other?
We should, and I promise it will get easier very soon. The big problem is that the current state of the dialog doesn't really allow for adding in new wizard pages. Any provider developer will then go in and do the following: * Save the current url in the textbox * Either remove the required attribute on the textbox or fill in a dummy url * Change the next wizard page When selecting away from the respective provider, the addon will then undo these changes. The problem is now that if multiple provider extensions do this, the reverting the changes from one addon will overwrite the intent to do the changes from the other provider. Then there are differences on how the changes are introduced. The Provider for MS Exchange overwrites some event handlers. I've been doing monkey patching in the Provider for Google Calendar. I've actually added in a hack to the Provider for Google Calendar to cope with the exchange provider, but given the latest version of Thunderbirthday worked for me and time was of the essence I didn't invest more time to find a workaround. As for the soon promised solution, I am working on completing a rewrite of the new calendar dialog from the GSoC code that Lenni had started and recently sent me an update on. The new dialog will allow for auto-detection and provide hooks so that no monkeypatching is needed. Simplifying it a little bit, the page to select the provider will also have radio buttons, but they have a few extra attributes. First of all a "nextpage" attribute, which will make the dialog code automatically select the next page when the provider is selected. Then there is an "onpageadvanced" attribute on the radio button that will also be called and checked for its return value. This way the provider can control the wizard page's onpageadvanced handler without having to overwrite it, or do complicated things like adding an event listener in js in the right order. There will also be a <deck> that holds a panel for the selected provider on the provider selection page. Thanks for the reduced testcase, I'll take a look at this in the next few days and let you know what the problem is, I'm sure I can find a solution that will work now.
Philipp sent me a patch that solves the immediate problem for ThunderBirthDay. Instead of defining an onload attribute in the xul file, the handler is added from a script. I do not understand why this would change something, but it solves my problem... Should I close the bug?
Yes I think we can close this one. Thanks for the report though!
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Thank you for working on and fixing this bug! Glad to have both of these extensions working again :)
You need to log in before you can comment on or make changes to this bug.