Closed Bug 1121289 Opened 9 years ago Closed 9 years ago

XUL content rendering issue in Firefox 36+?

Categories

(Core :: XUL, defect)

36 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla38
Tracking Status
firefox36 + wontfix
firefox37 + wontfix
firefox38 --- fixed

People

(Reporter: markus.popp, Unassigned, NeedInfo)

References

Details

I don't know if this problem is already known but I couldn't track it down to a particular bug report which already exists, so I'm reporting it here to make sure the problem is known and addressed.

There are some addons which stop working in Firefox 36. One of them is Speed Dial:

https://addons.mozilla.org/en-US/firefox/addon/speed-dial/

As I tried to find out if the addon is still being maintained and if the problem will be fixed, I received this reply from the developer:

https://addons.mozilla.org/en-US/firefox/addon/speed-dial/reviews/663052/

... in which he mentions a "XUL content rendering issue in tabs" which he says affects several addons and should be fixed by Mozilla.

I also found that the Video DownloadHelper addon:

https://addons.mozilla.org/en-US/firefox/addon/video-downloadhelper/

... ceases to work in Firefox 36. This may or may not be related to Speed Dial stopping to work.
Jorge, can you help on this? Thanks
Flags: needinfo?(jorge)
The dev reply you refer to is for Nightly, which is most likely an e10s issue, so it isn't something we should be alarmed about yet.

I recently posted this: https://blog.mozilla.org/addons/2015/01/13/compatibility-for-firefox-36/. My guess is that the VDH issue is related to the wrapper changes, but I can't be sure without further investigation. This is something each developer needs to deal with, though. I don't think there's any particular action to do here.
Flags: needinfo?(jorge)
(In reply to Jorge Villalobos [:jorgev] from comment #2)
> The dev reply you refer to is for Nightly, which is most likely an e10s
> issue, so it isn't something we should be alarmed about yet.

This particular issue also occurs in Firefox 36 and with e10s disabled. It doesn't seem to be related to e10s, at least not directly.
Hi, I'm Speed Dial's author; yes, there's a bug with all extensions that load "chrome://" XUL URLs.

More info in Bug 1098808
The issues seem to be documented and known. I won't block the 36 release for this.
Depends on: 1098808
Does that mean that FF36 will be released without the patch for bug 1083281? The sooner I know the better, so I can look for alternatives.

This problem will break extensions like FireFTP and Chatzilla.
(In reply to Josep del Rio from comment #6)
> Does that mean that FF36 will be released without the patch for bug 1083281?
> The sooner I know the better, so I can look for alternatives.
> 
> This problem will break extensions like FireFTP and Chatzilla.

Yes Firefox 36 will release without that patch, but e10s will be disabled so that particular issue won't break add-ons.
(In reply to Markus Popp from comment #3)
> (In reply to Jorge Villalobos [:jorgev] from comment #2)
> > The dev reply you refer to is for Nightly, which is most likely an e10s
> > issue, so it isn't something we should be alarmed about yet.
> 
> This particular issue also occurs in Firefox 36 and with e10s disabled. It
> doesn't seem to be related to e10s, at least not directly.

Are you still seeing this with e10s disabled? If so this isn't caused by bug 1098808.
(In reply to Dave Townsend [:mossop] from comment #8)
> Are you still seeing this with e10s disabled? If so this isn't caused by bug
> 1098808.

I just checked with today's Nightly and e10s disabled, the Speed Dial addon is still broken.

I don't think Firefox 36 should be released as long as addons using chrome:// URL are broken with e10s disabled. There are probably other addons as well which are broken.
I just checked it, and it's not working with e10s, but it doesn't appear to be a e10s problem.

It seems that for some reason a JS component is not registered properly, so I'll investigate further; from what I see, it's probably related to the extension's code.

Sorry about the confusion; I'll investigate the problem and I'm quite certain I should be able to sort it out soon enough.
Seems to impact more plugins than I thought, tracking back.
(In reply to Markus Popp from comment #9)
> (In reply to Dave Townsend [:mossop] from comment #8)
> > Are you still seeing this with e10s disabled? If so this isn't caused by bug
> > 1098808.
> 
> I just checked with today's Nightly and e10s disabled, the Speed Dial addon
> is still broken.
> 
> I don't think Firefox 36 should be released as long as addons using
> chrome:// URL are broken with e10s disabled. There are probably other addons
> as well which are broken.

chrome: urls should be working just fine with e10s disabled so there is something else going on here that we don't understand yet.

Josep, please let us know if you find out the cause so we can figure out if it's something we need to fix in Firefox.
Flags: needinfo?(peprio)
OK, just fixed it in my environment.

I'm quite certain it was a problem with an interface-less JS component; I was using the wrappedJSObject hack in order to avoid including a compiled IDL, but maybe it's no longer valid from FF36.

I created the IDL, compiled it with the Gecko SDK, included the resulting XPC in the manifest and the XPI, changed the component definition to use it, changed the component references to stop calling the wrappedJSObject, and then component worked as expected.
Under Firefox 38.0a1 (2015-01-15) is still not working. Waiting...
Josep, did you this the problem in speed dial itself? thanks
My impression is that there was a change in behavior in Firefox related to JS components; in the tutorials available from Mozilla it still states that it's possible to use the components without an interface by accessing the wrappedJSObject, and it may not be possible from the next release.

The fixed version is available from my website, and I'll upload it to AMO today.
(In reply to Josep del Rio from comment #16)
> My impression is that there was a change in behavior in Firefox related to
> JS components; in the tutorials available from Mozilla it still states that
> it's possible to use the components without an interface by accessing the
> wrappedJSObject, and it may not be possible from the next release.

This is surprising, we use the wrappedJSObject feature throughout Firefox code itself so I'm surprised to hear that it stopped working. Can you give more details on what specifically you were using it for that might help me build a simplified testcase that shows the problem? As an example, trying the following code in a browser scratchpad shows the alert as expected showing that at least in this case wrappedJSObject is working:

Services.obs.addObserver(function(subject) {
  subject.wrappedJSObject.alert();
}, "test-wrappedjsobject", false);

var fake = {
  alert: function() {
    alert("Got here");
  }  
}
fake.wrappedJSObject = fake;

Services.obs.notifyObservers(fake, "test-wrappedjsobject", false);
Firefox 38.0a1 (2015-02-03) looks that has solved the problem. 
May some body else confirm it?
(In reply to caralu1974 from comment #18)
> Firefox 38.0a1 (2015-02-03) looks that has solved the problem. 
> May some body else confirm it?

Is there someone else who can confirm? If we have successfully fixed this issue, it may be worth tracking down the fix so that we can uplift it to at least 37.
Too late for 36 but tracking it for 37 in case we find the patch which fixed it.
(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #19)
> (In reply to caralu1974 from comment #18)
> > Firefox 38.0a1 (2015-02-03) looks that has solved the problem. 
> > May some body else confirm it?
> 
> Is there someone else who can confirm? If we have successfully fixed this
> issue, it may be worth tracking down the fix so that we can uplift it to at
> least 37.

mossop - You've been active in this bug. Can you track down the fix so that we can uplift to 37? If not, I suggest that this is going to ride the 38 train.
Flags: needinfo?(dtownsend)
Not really no. The initial comments talked about a bug that is e10s only but comment 9 says it happens with e10s disabled. The clearest suggestion of what the bug might be is in comment 16 but I can't reproduce that either.

Josep is there a clear testcase that can show us what was broken here?
Flags: needinfo?(dtownsend)
As stated in comment 16, Speed Dial has been fixed. According to comment 18, this bug has been fixed in 38. Given the limited time left in the 37 cycle, the limited reports about this issue, and that there is a fix that can be done by the add-on author, I'm going to resolve this as fixed in 38 and wontfix for 37.

I'm happy to have this reopened if there is additional information available or if it turns out that the report of this bug being fixed in 38 was incorrect.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
The issues which made me file this report are all fixed, so from my perspective it's fine to close it.
You need to log in before you can comment on or make changes to this bug.