59130 - Mozilla crashes when clicking on any story link

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Stephen Moehle]

Go to The Register site at the URL above.  Click on any of the story links.
Mozilla will crash.  Happens every time.  This is a recent regression within the
past couple of days.  The Talkback incident id is TB20393540Y.

Tested with Mozilla 110406 trunk build on Linux.

Comment 1

[Gilles Durys]

wfm with 2000110304 win32
I'll try with a more recent build when it's available

Comment 2

[Chris McAfee]

wfm, branch winNT 4.0 11/4 build

Comment 3

[Doron Rosenberg (IBM)]

reporter: could you try with a new profile? thanks!

Comment 4

[Stephen Moehle]

I created a new profile, and it is still crashing.  Everyone seems to be testing
with NT even though I am reporting this on Linux.

Comment 5

[Stephen Moehle]

I went back and installed Mozilla 110306 trunk build, and everything worked
fine.  I then installed 110406 again, and the crashing came back.

I am also crashing if I go to http://linuxtoday.com/ and click on any of the
story links.  The Talkback id for that is TB20396876K.

Comment 6

[Boris Zbarsky [:bzbarsky]]

I'm seeing this on Linux 2000110406 as well.  Running with --debug, I get:

Program received signal SIGSEGV, Segmentation fault.
0x403affef in nsFocusController::UpdateCommands ()
   from /home/bzbarsky/moztest/package/libjsdom.so

which is the same message as I see for bug 59129.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Confirming.  Stack:

#0  0x40558137 in nsFocusController::UpdateCommands (this=0x823e4f8,
    aEventName=@0xbfffe698)
    at /builds/seamonkey/mozilla/dom/src/base/nsFocusController.cpp:126
#1  0x40559ad1 in nsFocusController::SetSuppressFocus (this=0x823e4f8,
    aSuppressFocus=0)
    at /builds/seamonkey/mozilla/dom/src/base/nsFocusController.cpp:351
#2  0x40f8bf1e in nsDocShell::SetupNewViewer (this=0x84e9268,
    aNewViewer=0x84890a8)
    at /builds/seamonkey/mozilla/docshell/base/nsDocShell.cpp:2852
#3  0x40f953c7 in nsWebShell::SetupNewViewer (this=0x84e9268,
    aViewer=0x84890a8)
    at /builds/seamonkey/mozilla/docshell/base/nsWebShell.cpp:350
#4  0x40f8a033 in nsDocShell::Embed (this=0x84e9268, aContentViewer=0x84890a8,
    aCommand=0x40fbaaa4 "", aExtraInfo=0x0)
    at /builds/seamonkey/mozilla/docshell/base/nsDocShell.cpp:2505
#5  0x40f955c1 in nsWebShell::Embed (this=0x84e9268, aContentViewer=0x84890a8,
    aCommand=0x40fbaaa4 "", aExtraInfo=0x0)
    at /builds/seamonkey/mozilla/docshell/base/nsWebShell.cpp:379
#6  0x40f8aad5 in nsDocShell::CreateContentViewer (this=0x84e9268,
    aContentType=0xbfffed40 "text/html", aOpenedChannel=0x838af90,
    aContentHandler=0xbfffedd8)
    at /builds/seamonkey/mozilla/docshell/base/nsDocShell.cpp:2692
#7  0x40f9bcb3 in nsDSURIContentListener::DoContent (this=0x84e8dd8,
    aContentType=0xbfffed40 "text/html", aCommand=7,
    aWindowTarget=0x40183d08 "", aOpenedChannel=0x838af90,
    aContentHandler=0xbfffedd8, aAbortProcess=0xbfffed88)
    at /builds/seamonkey/mozilla/docshell/base/nsDSURIContentListener.cpp:102
#8  0x40fe234e in nsDocumentOpenInfo::DispatchContent (this=0x83eae98,
    aChannel=0x838af90, aCtxt=0x0)
    at /builds/seamonkey/mozilla/uriloader/base/nsURILoader.cpp:367
#9  0x40fe1b11 in nsDocumentOpenInfo::OnStartRequest (this=0x83eae98,
    aChannel=0x838af90, aCtxt=0x0)
    at /builds/seamonkey/mozilla/uriloader/base/nsURILoader.cpp:241
#10 0x40e143a7 in nsHTTPFinalListener::OnStartRequest (this=0x83eaed8,
    aChannel=0x838af90, aContext=0x0)
    at
/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHTTPResponseListener.cpp:1122
#11 0x40e4caf8 in InterceptStreamListener::OnStartRequest (this=0x84e4790,
    channel=0x838af90, ctxt=0x0)
    at /builds/seamonkey/mozilla/netwerk/cache/mgr/nsCachedNetData.cpp:1190
#12 0x40e13e5f in nsHTTPServerListener::FinishedResponseHeaders (
    this=0x84e5be0)
    at
/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHTTPResponseListener.cpp:1048
...

Using debug build from an hour or so ago.

Comment 8

[Doron Rosenberg (IBM)]

according to lxr, this seems to be hyatt's fix for 
http://bugzilla.mozilla.org/show_bug.cgi?id=54203.  ccing him

upping severity, regression

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

-> hyatt

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The crash is occurring when the window gains focus after the new document is
displayed, or when the new doc is displayed if the window already has focus.  A
null check (for domDoc) seems to fix the crash.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: null check that fixes bug

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm guessing that mCurrentElement was still something from the previous
document, and it had had it's document set to null in the teardown.  gdb5 isn't
very cooperative today, so I'm not going to test that theory...

Comment 13

[David Hyatt]

Yes, this patch is absolutely correct, even down to leaving mCurrentElement set. 

a=hyatt

saari should review.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 59129 has been marked as a duplicate of this bug. ***

Comment 15

[John Morrison]

So for bug 59102 -- where installing new skins, clobbers existing ones, a 
fix was checked into the trunk so I could test the official bits this evening.

But this bug means that you crash on skin-switching, including when you trigger 
install a new skin --- SO, we need this patch checked into the trunk -- it's 
just a null pointer check and skin-switching works with it in the code 
(tested).

Can we round out someone to put this into the trunk and get dispensation to 
do so (it has a=hyatt, but not yet an r=). This needs to happen by 8pm to get
into the next spins.

Comment 16

[John Morrison]

Adding some more names to get someone who can check this in -- need it for 
testing tonight (8pm).

Comment 17

[Ben Goodger (use ben at mozilla dot org for email)]

In the absence of Chris Saari, and wanting to get some testing behind 59102, I'm 
giving this r=ben and checking in the fix. This patch is small and looks 
reasonable, and if there are problems we can back it out. 

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

marking fixed because dbaron's patch has been checked in. 

Comment 19

[Alex]

*** Bug 59141 has been marked as a duplicate of this bug. ***

Comment 20

[mmclure]

*** Bug 59186 has been marked as a duplicate of this bug. ***

Comment 21

[saari (gone)]

Well, it is a little late, but r=saari

Comment 22

[John Morrison]

verified fixed (saari missed all the fun).