1189434 - Firefox commit 66d93422384f appears to break the FireGestures and other addons

Status: RESOLVED INVALID

(WebExtensions :: General, defect)

Description

[Chris Siebenmann]

As of commit 66d93422384f (as located through 'hg bisect'), Firefox Nightly doesn't work with the FireGestures addon. The addon still displays eg gesture mouse trails but actual gestures in browser windows appear at best non-functional and sometimes gesture information doesn't even appear.

Environment:

64-bit Fedora 22 Linux, all current updates.

Reproduction:
1. Start with a clean Firefox environment
2. Install FireGestures
3. Attempt to do any gestures; nothing happens. If you go to FireGestures' preferences and look at the mappings tab, it will be empty of gestures.
4. Load a saved gestures database backup from a working install on a previous version of Firefox, then quit and restart Firefox Nightly. Now making gestures will show you the mouse trails but won't even pop up the 'Gesture: ....' information at the bottom of the window.

Comment 1

[(no longer active)]

I don't think there's anything we should do here.  That extension needs to be updated.

Comment 2

[Chris Siebenmann]

Is there an easy explanation of the problem and/or the fix to make that
I can pass on to the FireGestures author?

(Thanks in advance.)

Comment 3

[(no longer active)]

What we have done is change the DOM structure that implements our tabs by adding a new element.  If you manage to contact the author of the add-on, please feel free to put them in touch with me, and I will try to help them out.  The specific solution depends on what the add-on is trying to do.

Comment 4

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

Ehsan, which bug does that commit correspond to?

Comment 5

[Chris Siebenmann]

I've submitted this to the FireGestures Github repo as https://github.com/gomita/firegestures/issues/99 .

Comment 6

[(no longer active)]

(In reply to Jorge Villalobos [:jorgev] from comment #4)
> Ehsan, which bug does that commit correspond to?

Bug 486262.

Comment 7

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

The relevant bug has been flagged for our compatibility comms and the developer has been contacted per comment #5. There's nothing more to do here.

Comment 10

[YF (Yang)]

The also broke the Tab Utilities Fixed (https://addons.mozilla.org/firefox/addon/tab-utilities-fixed/), I just updated it (https://github.com/yfdyh000/tabutils/releases), the previous versions was completely broken, No any functions, and just an error "undefined entity" in Browser Console, the break is difficult to detect the reason, I found the bug through "mozregression" tool.


Maybe we should consider a shim, like keep the dtd file with comment, or other mechanism. And, at least a AMO checks and note on MDN (https://developer.mozilla.org/en-US/Firefox/Releases/43#Changes_for_add-on_and_Mozilla_developers).

Comment 11

[(no longer active)]

FireGesture has been fixed already.  Not sure why you think this bug needs to be reopened.

Comment 12

[(no longer active)]

FWIW, according to the addons mxr, 44 add-ons include the string "tabbrowser.dtd".  Is this enough of a reason for us to add a shim file with that name back to the codebase?

Comment 13

[Jared Wein [:jaws] (please needinfo? me)]

I'm curious how many of those add-ons are trying to use the entity version of the closeTab.label string? I'm fine with adding a blank tabbrowser.dtd file back along with a comment inside of the file saying that it is here for legacy reasons (and that the comment can be removed if a string is added to the file).

We probably can't add that string back due to l10n freeze on Aurora.

Comment 14

[YF (Yang)]

(In reply to Ehsan Akhgari (don't ask for review please) from comment #11)
> FireGesture has been fixed already.  Not sure why you think this bug needs
> to be reopened.

Addons developers is difficult to find the cause of the problem if the problem occurs.

At least to follow up for adding this point to MDN's developer note and verification process (checklist) on AMO. Or send a batch messages to add-ons developers of involving this point, to inform this point.


Also, throw the "undefined entity" error when referenced dtd not found is an expected behavior? We may need a new bug to change this, like a special message and/or skip it.

Comment 15

[Dão Gottwald [:dao]]

(In reply to Ehsan Akhgari (don't ask for review please) from comment #12)
> FWIW, according to the addons mxr, 44 add-ons include the string
> "tabbrowser.dtd".  Is this enough of a reason for us to add a shim file with
> that name back to the codebase?

I don't think so.

(In reply to YF (Yang) from comment #14)
> At least to follow up for adding this point to MDN's developer note and
> verification process (checklist) on AMO. Or send a batch messages to add-ons
> developers of involving this point, to inform this point.

We don't formally track this in bugzilla, but Jorge is already aware of this (bug 486262 comment 178).

Comment 16

[(no longer active)]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #13)
> I'm curious how many of those add-ons are trying to use the entity version
> of the closeTab.label string? I'm fine with adding a blank tabbrowser.dtd
> file back along with a comment inside of the file saying that it is here for
> legacy reasons (and that the comment can be removed if a string is added to
> the file).

closeTab.label is also defined in browser.dtd! <http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/browser/browser.dtd#52>  In the case of FireGesture, the breakage was literally due to the removal of tabbrowser.dtd.  The extension did not depend on the contents of that file in any way.

(In reply to Dão Gottwald [:dao] from comment #15)
> (In reply to Ehsan Akhgari (don't ask for review please) from comment #12)
> > FWIW, according to the addons mxr, 44 add-ons include the string
> > "tabbrowser.dtd".  Is this enough of a reason for us to add a shim file with
> > that name back to the codebase?
> 
> I don't think so.

OK, so if you guys end up agreeing, let me know.  :-)