1070728 - RefControl errors in the browser console with e10s

Status: RESOLVED WORKSFORME

(Firefox :: Extension Compatibility, defect)

Description

[Gingerbread Man]

Attachment: errorlog_refcontrol.txt

https://addons.mozilla.org/firefox/addon/refcontrol/

Simply opening a new tab results in the Browser Console being flooded with the attached error messages. Basic functionality seems to still work however: the console shows the referrer header is appropriately not sent, as configured in RefControl.

Comment 1

[Chris Peterson [:cpeterson]]

James, are you the author of the RefControl add-on?

Your add-on seems to be broken with multiprocess Firefox (e10s). If you have any questions about e10s support, just drop by the #e10s IRC channel on irc.mozilla.org. MDN also has a good introduction:

https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

The developer has been notified through AMO. The add-on hasn't been updated in three years, though.

Comment 3

[James Abbatiello]

I have a version available for testing at http://www.stardrifter.org/refcontrol/RefControl-0.8.17pre2.xpi that I believe solves this problem.

Any results from testing would be appreciated.

Comment 4

[Gingerbread Man]

Looks good to me. I'm no longer seeing either the reported issue, or the errors that would pop up when opening the RefControl Options window. I've also quickly checked two instances where the referrer wasn't sent (default), and where it was sent (exception): the behavior was appropriate.

Therefore, I think it's safe to mark this as WORKSFORME. Thank you very much for the fix. It's appreciated.

Comment 5

[Frederik Braun [:freddy]]

Why not resolved/fixed?

James: Will you submit this to addons.mozilla.org / Have you submitted it?

Comment 6

[Gingerbread Man]

(In reply to Frederik Braun [:freddyb] from comment #5)
> Why not resolved/fixed?

“Resolve a bug as FIXED if the bug has been fixed by a checkin into the Mozilla Mercurial code repository. Bugs which can no longer be reproduced should be marked WORKSFORME instead of FIXED if they can't be linked to a single checkin.

In general you can resolve a bug as WORKSFORME if… the bug can't be reproduced with a current build.”
— https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla

Comment 7

[Gingerbread Man]

I think I wasn't clear before, so I'll try explaining again.

I can no longer reproduce the issue in this report's description. That's with the 2014-12-04 64-bit Nightly and RefControl 0.8.16, the latest currently on AMO. Since it's something in Firefox that fixed this, but I don't know what, I marked this WORKSFORME.

RefControl 0.8.17pre2 is still a welcome fix, because it doesn't have these issues seen with 0.8.16:
* Regardless of where e10s is on or off, when opening the RefControl Options window, the browser console gets flooded with errors.
* With e10s disabled, there are errors in the browser console as soon as Nightly starts up (that is, the errors are there the moment I open the browser console).

Each version was tested in a brand new profile where RefControl was the only add-on installed. The only modified settings were the following, since otherwise e10s would be disabled due to an IME being detected:
browser.tabs.remote.autostart.1 false
browser.tabs.remote.autostart true