Closed Bug 1189434 Opened 4 years ago Closed 4 years ago

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

Categories

(WebExtensions :: General, defect, major)

Firefox 42
defect
Not set
major

Tracking

(firefox41 unaffected, firefox42 affected, firefox43 affected)

RESOLVED INVALID
Tracking Status
firefox41 --- unaffected
firefox42 --- affected
firefox43 --- affected

People

(Reporter: cks+mozilla, Unassigned)

References

Details

(Keywords: addon-compat)

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.
I don't think there's anything we should do here.  That extension needs to be updated.
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.)
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.
Ehsan, which bug does that commit correspond to?
Flags: needinfo?(ehsan)
I've submitted this to the FireGestures Github repo as https://github.com/gomita/firegestures/issues/99 .
(In reply to Jorge Villalobos [:jorgev] from comment #4)
> Ehsan, which bug does that commit correspond to?

Bug 486262.
Flags: needinfo?(ehsan)
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.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
Duplicate of this bug: 1190034
Blocks: 486262
Component: Extension Compatibility → Add-ons
Product: Firefox → Tech Evangelism
Duplicate of this bug: 1192614
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).
Severity: normal → major
Status: RESOLVED → REOPENED
Keywords: addon-compat
Resolution: INVALID → ---
Summary: Firefox Nightly commit 66d93422384f appears to break the FireGestures addon under some circumstances → Firefox commit 66d93422384f appears to break the FireGestures and other addons
FireGesture has been fixed already.  Not sure why you think this bug needs to be reopened.
Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → INVALID
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?
Flags: needinfo?(jaws)
Flags: needinfo?(dao)
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.
Flags: needinfo?(jaws)
(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.
(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).
Flags: needinfo?(dao)
(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.  :-)
Component: Add-ons → General
Product: Tech Evangelism → WebExtensions
You need to log in before you can comment on or make changes to this bug.