Closed Bug 734019 Opened 8 years ago Closed 8 years ago

The big picture hangs , and finally Browser crashes with null signature

Categories

(Core :: DOM: Core & HTML, defect)

11 Branch
x86_64
All
defect
Not set

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox11 + wontfix
firefox12 - affected
firefox13 + fixed
firefox14 + unaffected

People

(Reporter: djc, Assigned: Ms2ger)

References

()

Details

(Keywords: addon-compat, regression)

Attachments

(3 files)

The URL makes Aurora reliably hang (12.0a2 from 2012-03-04 on Windows 7).
Duplicate of this bug: 735847
There are a number of open bugs with slowness/hangs/crashes on http://www.boston.com/bigpicture/, like bug 734746, bug 735437, bug 735440, bug 735441, bug 735446 and bug 735811. Additionally bug 734129 is a crash that has been fixed in FX13.
I can reproduce on Firefox11.0-14.0a1.

"Warning: Unresponsive script" dialog Pops up and UI is locked.
And finally Browser crashes with null signature.

Step To Reproduce:
1. Start Firefox with clean profile
2. Open http://www.boston.com/bigpicture/2012/03/
3. Click  link "Japan tsunami pictures: before and after"

Actual Results:
"Warning: Unresponsive script" dialog Pops up and UI is locked.
And finally Browser crashes with null signature.

bp-ddaa53c7-7d54-4690-922b-9c3a02120315
bp-edebf2d2-8a94-42b4-9f27-b04152120315


Regression window

No hung up, no "Warning: Unresponsive script" dialog.
And works properly:
http://hg.mozilla.org/mozilla-central/rev/a5e63e00db27
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111218 Firefox/11.0a1 ID:20111218031140

"Warning: Unresponsive script" dialog Pops up and UI is locked
And finally Browser crashes with null signature:
http://hg.mozilla.org/mozilla-central/rev/543af61eee05
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111218 Firefox/11.0a1 ID:20111218021643

Script: http://w.sharethis.com/button/sharethis.js#tabs=web%2Cpost&charset=utf-8&services=facebook%2Cdigg%2Cstumbleupon%2Ctwitter%2Creddit%2Cdelicious%2Cmixx%2Cmyspace%2Cnewsvine%2Cblogger%2Ctypepad%2Cwordpress%2Ctechnorati%2Clinkedin%2Cslashdot%2Cgoogle_bmarks%2Cyahoo_bmarks%2Cwindows_live%2Cfriendfeed%2Cpropeller%2Cblogmarks%2Cfurl%2Cblinklist%2Cfriendster&style=default&publisher=9afb63cc-565b-4af5-8f8b-95034feb717c:1

  function SHARETHIS_unlink(c) {
    var a;
    switch (SHARETHIS_typeof(c)) {
    case "object":
      a = {};
      for (var e in c) {
>>      a[e] = SHARETHIS_unlink(c[e])
      }
      break;
    case "hash":



Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a5e63e00db27&tochange=543af61eee05

Last good :c3525cd1ce44
First bad :f9f6f9ed788a

Triggered by
f9f6f9ed788a	Ms2ger — Bug 707576 - Remove nsIDOMNSElement; r=smaug
Blocks: 707576
Component: Untriaged → DOM
Keywords: regression
Product: Firefox → Core
QA Contact: untriaged → general
Version: 12 Branch → 11 Branch
OS: Windows 7 → All
Summary: The big picture hangs Aurora → The big picture hangs , and finally Browser crashes with null signature
This is a pretty commonly visited site....
Tracking for 11 through 14. We may consider this as a ride-along if we chemspill for FF11.

ms2ger - please prepare a backout patch of bug 707576 for Aurora 13 and Beta 12 so that we can test the backout ahead of a possible chemspill.
Assignee: nobody → Ms2ger
I tried today and I'm not able to reproduce the chromehangs (with not responding/unresponsive script warnings), it appears the website has modified its code. Anyway maybe the patch of bug 707576 should be re-examined and tested.
Can't reproduce here. I get two slow script warnings, but no real hang and no crash.
Do you get the slow script warnings with nighties from before the range in comment 4?
Attached file Saved page
I cannot reproduce on the URL comment2 in Firefoc11-14.0a1 anymore.(Though I can reproduce with attachment 606705 [details])
So I _think_ what happens here is that the big inline script has SHARETHIS_merge caled on two objects, one of which has an "element" property (an HTMLSpanElement) and one of which does not.  In particular, f ends up as undefined, while g is an HTMLSpanElement, so SHARETHIS_unlink is called on the HTMLSpanElement.

And if you look at SHARETHIS_unlink, calling it on any element of a data structure with loops (e.g. a DOM) will put it in an infinite loop.

So presumably we used to not end up landing in there at all....
I think we should strongly consider backing out bug 707576 (assuming that addresses the issue) on aurora and beta if we don't have another fix plan soonish...
Ms2ger, could you prepare a backout patch?
Ms2ger, ping.
https://hg.mozilla.org/try/rev/873519bccfed appears to work (for aurora)
Attached patch Beta backoutSplinter Review
Attachment #613656 - Flags: review?(bugs)
Attached patch Aurora backoutSplinter Review
Attachment #613658 - Flags: review?(bugs)
Attachment #613656 - Flags: review?(bugs) → review+
Attachment #613658 - Flags: review?(bugs) → review+
Comment on attachment 613656 [details] [diff] [review]
Beta backout

[Approval Request Comment]
Regression caused by (bug #): bug 707576
User impact if declined: The big picture hangs
Testing completed (on m-c, etc.): Passes try
Risk to taking this patch (and alternatives if risky): Reverts to the previous state
String changes made by this patch: None
Attachment #613656 - Flags: approval-mozilla-beta?
Comment on attachment 613658 [details] [diff] [review]
Aurora backout

[Approval Request Comment]
Regression caused by (bug #): bug 707576
User impact if declined: The big picture hangs
Testing completed (on m-c, etc.): Passes try
Risk to taking this patch (and alternatives if risky): Reverts to the previous state
String changes made by this patch: None
Attachment #613658 - Flags: approval-mozilla-aurora?
Comment on attachment 613656 [details] [diff] [review]
Beta backout

[Triage Comment]
Approving this backout for Beta 13 since it caused a web regression. Please land asap.
Attachment #613656 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #613658 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
It seems this backout has broken building of the Eudora importer in Thunderbird Beta Mac builds:
http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird-Beta/1334097653.1334101565.32224.gz&fulltext=1
Yes, it would, given that the original landing did as well. The long-term fix is bug 684466.
FYI this backout broke comm-based builds [see-also c#23/24], I just found out with a SeaMonkey beta build run [after not double checking that comm-beta itself was green].

It is rare that a change breaks us, but if possible can we *try* to give an explicit heads up in the future?

This fix should be relatively simple its just not a fix I can do tonight [and rekick release automation in time for the hg outage tomorrow]

If no-one beats me to it, I'll try and whip together a patch to fix comm tomorrow sometime after the hg outage.
This is relatively simple to fix, you only need to back out this from comm-beta:
http://hg.mozilla.org/releases/comm-beta/rev/2086df5c1eab
I've done this yesterday on my hard drive and now it builds again. :-)
Justin, sorry about that.  I didn't realize this patch affected comm-central when I pushed; otherwise I would have pinged you guys...
I can fix this...
Depends on: 745453
This backout involved a rather significant IDL change after beta, which means that binary addons which compiled against beta1 (which is what we recommend) are now crashing or displaying other odd behavior (see bug 745453). Adding the addon-compat keyword, but is there a way we could have accomplished the core of this backout without the IDL changes? Is this something we can undo?
Keywords: addon-compat
The point of the patch being backed out was to merge one interface into another.  The backout, if done, kinda has too unmerge the interfaces, and that does involve iid changes...

The only other option is to find which part of the interface merge, exactly, broke the site and try to fix that part assuming _that's_ possible without IDL changes.

Of course we can undo the backout; that will re-break the site in question (which is pretty popular).
And I'm really sorry the backout didn't happen much sooner.  :(
(In reply to Boris Zbarsky (:bz) from comment #32)
> And I'm really sorry the backout didn't happen much sooner.  :(

Let's backout the backout on mozilla-beta if it resolves bug 745453. Losing Mac users is a much bigger risk than the web regression with big picture. Searching through input, there's maybe one mention of big picture w/r/t FF11.
I'd like to get some QA around this issue prior to relnoting for FF12, since I have a sneaking suspicion that boston.com has employed a workaround.
Keywords: qawanted
(In reply to Alex Keybl [:akeybl] from comment #35)
> I'd like to get some QA around this issue prior to relnoting for FF12, since
> I have a sneaking suspicion that boston.com has employed a workaround.

QA has not been able to reproduce the issue across multiple OSs and versions. I don't think we need to track this for release any longer.
Duplicate of this bug: 734746
Not exactly reproducible anymore....
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
[Triage Comment]
Updating status for 14, looks like this was never landed to central (when central was 14) so it shouldn't be affected here.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.