Conflict with Dictionary Switcher

Bug #1249920 reported by Kevin Cox
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Searchbar Autosizer
Confirmed
Medium
Unassigned

Bug Description

There's a conflict with Dictionary Switcher: The first time we try to open the Wizard, only the buttons ("Back", "Finish", and "Cancel") are visible and it seems that the page opens up on the last configuration panel (the "Finish" button appears instead of "Next"). Closing and relaunching the Wizard resolves the issue.

Revision history for this message
Kevin Cox (kevincox) wrote :

- **status**: open --> accepted

Revision history for this message
Kevin Cox (kevincox) wrote :

Okay, that's really strange. I have no idea what we are doing that could cause that but I'll look into it.

Revision history for this message
Kevin Cox (kevincox) wrote :

Closing and relaunching does not fix this for me.

Revision history for this message
Kevin Cox (kevincox) wrote :

Steps to reproduce:

##Meathod 1
 - Navigate to `chrome://autosizer/content/wizard.xul`.
 - Notice there is no text.

##Meathod 2
 - Navigate to `about:addons`
 - Find Searchbar Autosizer and click the preferences button.
 - Click "Assistant"
 - Notice there is no text.

Revision history for this message
Kevin Cox (kevincox) wrote :

You can get the expected behavior by disabling Dictionary Switcher and repeating either of the steps.

Revision history for this message
kingn0thing (kingn0thing) wrote :

I haven't thoroughly looked at it, but when Dictionary Switcher is installed, SBA doesn't call asw.initSize() before asw.init() the first time the Wizard is launched.

Revision history for this message
Kevin Cox (kevincox) wrote :

Yes, here is the log:

    autosizer: asw.init() called.
    autosizer: asw.init() returned.

What's more, there are no error console errors. Seeing as printing "autosizer: asw.initSize() called." is the first line of `asw.initSize()` I would say that this is either a Mozilla or Dictionary Switcher bug as we just aren't getting called.

What the log looks like without DS installed:

    autosizer: asw.initSize() called.
    autosizer: asw.initSize() returned.
    autosizer: asw.init() called.
    autosizer: asw.init() returned.

Seeing as `asw.initSize()` is the first page of the wizard it is like we aren't opening to the proper page.

I think we need to try to isolate the mistake, quite likely by guess and check.

Revision history for this message
Kevin Cox (kevincox) wrote :

As a workaround disable Dictionary Switcher when you need to use the wizard. That appears to be the only thing affected.

Revision history for this message
Kevin Cox (kevincox) wrote :

Here is a quick log of things I am testing.

 - Comment out DS's browser.xul overlay in chrome.manifest.
     - The Wizard works.
 - Comment out contents of `<overlay>` in br_tbarpal.xul
     - Does nothing.
 - Comment out contents of `<overlay>` in browser.xul
     - Wizard works.
 - Comment out browser.js either in browser.xul or by commenting out the whole file.
     - Wizard works.
 - Commenting out window load listener in browser.js.
     - Wizard does not work.
 - Comment out the rest of browser.xul (not the script tag)
     - Wizard works.
 - Comment only `<menupopup> browser.xul
     - Wizard works.
 - Comment out contents of `<menupopup> browser.xul
     - Wizard works.
 - Comment out either (or both) of `<menuitem id="dictionary-switcher-as-i-type">` and `<menuitem id="dictionary-switcher-auto">`
     - Wizard works.
 - Comment out either (or both of) `dictionarySwitcher.toggleAsIType()` and `dictionarySwitcher.toggleAuto()`
     - Wizard does not work.
     - That is really strange.
 - Comment out the oncommand attribute of the mentioned menuitems.
     - Wizard does not work.
 - Remove either (or both) of the mentioned menuitems' id's.
     - Wizard works.
     - My brain is refusing to believe this.
 - Comment out all document.getElementById to the two menuitems.
     - Wizard does not work.

I'm totally confused and need to take a break. If **either** of the menuitems are there it works, so not one is causing the problem, it is the combination of both. I was thinking if they were indexing the children it could grab the wrong one or something but I can't find any reference to that. Hopefully the author has some insight.

Revision history for this message
Kevin Cox (kevincox) wrote :

Hello, I took another look a couple of times and still have no clue. Is this issue still present or has it magically disappeared?

Revision history for this message
kingn0thing (kingn0thing) wrote :

This issue is still present (successfully reproduced with Firefox 24.0, Windows 7 SP1 - x86).

Still no error in the log, besides a "XUL box for a element contained an inline #text child, forcing all its children to be wrapped in a block" message, pertaining to prefs.xul.

Kevin Cox (kevincox)
Changed in autosizer:
status: Triaged → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.