Closed Bug 966716 Opened 7 years ago Closed 4 years ago
"Similar Sites" addon prevents Firefox 27+ from opening ANY new windows
STR: 1. Install the "Similar Sites" addon: https://addons.mozilla.org/en-US/firefox/addon/similarsites/ 2. Restart Firefox from the terminal so you can watch stderr for assertion failures. RESULT: On OS X, the Firefox menubar appears and is functional, but no window opens. The "New Window" command does not open any new windows, either. If I disable the "Similar Sites" addon and restart Firefox, then windows appear as expected. I believe this is a regression in Nightly 27 build 2013-09-27. I used mozregression to bisect Nightly and mozilla-inbound builds to this regression range: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d9d845045319&tochange=3ad5ecf34c9e Unfortunately, I can't build any of the pushlog's changesets locally because of various compilation errors. Because this bug prevents Firefox from working AT ALL and it rode the trains to Beta 27, I must assume the "Similar Sites" addon does not have many users and is not actively maintained. (Its last release was March 2013.)
Nick: could this bug be a regression from your fix for ActorDestroy bug 907463?
(In reply to Chris Peterson (:cpeterson) from comment #2) > Nick: could this bug be a regression from your fix for ActorDestroy bug > 907463? I would be suprised if it was because the patch does not touch any of the windowing code - only graphics stuff (so if the window were opening and it were all black or something, then it might be to blame. The window not opening at all makes it unlikely). You could try disabling OMTC from about:config and see if that makes a difference - if it does, then it makes that bug more likely (although it could still be something else), if it doesn't make any difference, then it is certainly something else.
Setting layers.acceleration.disabled=true had no effect on this bug, so it is not an OMTC regression.
It has 200K users and perhaps none or few of them are on channels outside of release. Jorge - do we have a way to notify users that their addon is causing the behaviour without straight-up blocking it? If not, should we block this and try to reach out to the developer?
Can this be consistently reproduced on OS X, in a clean profile? I tested on Windows 7 and didn't see any problems, and I also don't see any feedback about this in any of the usual channels. If this only affects OS X, then the usage numbers go down to 1.6K, which is much less worrisome. I think we need to first see how easy it is to reproduce and whether the blocklist would even work under these circumstances. We can mark the add-on as incompatible with 27 and above to prevent users from activating it when they move to 27, but it'll affect all users, so I'd rather avoid that if possible.
This problem is not as reproducible as I thought. It is not 100% reproducible from a clean profile, but if I alternately load the same profile in Nightly 30 and Beta 28, then the problem *seems* to happen more often, especially when switching from Nightly back to Beta. At that point, the profile "goes bad" and won't load in Firefox 27+ (but will open in earlier versions). Perhaps this is a race related to profile upgrading? I switch browsers often for testing (using the same profile), so maybe I am seeing a problem that typical users upgrading from Firefox 26 wouldn't see.
It could be related to Australis. Can you try alternating between 28 and 29?
This problem is not related to Australis because I was able to reproduce the problem when only switching between Firefox 27 and Beta 28. I created two clean profiles and installed the Similar Sites addon in both. Switching between 27 and 28, I was able to get one profile in a bad state where I was able to trigger the problem 100% reliably. I diffed the good and bad profile directories. I didn't see any suspicious differences. I started replacing the bad profile's files with the good profile's files one-by-one to see if one of the files would "fix" the problem. None of them did. Eventually my good and bad profile directories were *identical* and yet I could still reproduce the problem 100% reliably with the "bad profile"?! Is there some Firefox or addon state that is managed outside the profile directories?
Alexander: I used mozregression to bisect Nightly and mozilla-inbound builds and I believe this regression is from bug 943482 ("remove a11y support of not existing xul:menulist@droppable").
(In reply to Chris Peterson (:cpeterson) from comment #10) > Alexander: I used mozregression to bisect Nightly and mozilla-inbound builds > and I believe this regression is from bug 943482 ("remove a11y support of > not existing xul:menulist@droppable"). can we reach the addon author? They shouldn't use a11y for UI stuff.
I don't see an instances of "droppable" or anything similar in this extension's code. Should I be looking for something else?
A few changesets after bug 943482 landed, bug 960771 ("Uplift Add-on SDK") landed. Updating Firefox's addon SDK *sounds* like a likely source of addon regressions, but after my mozregression bisection, I am pretty confident that it was NOT the source of the regression.
See Also: → 960771
Given the non-reproducibility on Windows, lack of user feedback in amo channel, and that this isn't 100% reproducible this isn't a blocker for FF27 release/unthrottling.
Is this still an issue in a recent build?
WFM with Nightly 51 and Similar Sites version 3.0.3.
You need to log in before you can comment on or make changes to this bug.