Closed
Bug 982298
Opened 10 years ago
Closed 10 years ago
crash in mozilla::ScrollFrameHelper::ScrollToImpl(nsPoint, nsRect const&, nsIAtom*)
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
VERIFIED
FIXED
mozilla31
People
(Reporter: nthomas, Assigned: m_kato)
References
Details
(Keywords: crash, regression)
Crash Data
Attachments
(2 files)
4.22 KB,
patch
|
roc
:
review+
lsblakk
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
722 bytes,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
This bug was filed from the Socorro interface and is report bp-aa847442-e4dc-4fe5-a276-68abd2140311. ============================================================= One way to hit this is: * start editing a wiki.m.o page * use cmd-f to search for a word * click the 'Show preview' button, or 'Page' in the header * search again with cmd-g (nothing happens) * search again with cmd-g (crashes) More crash reports: bp-30c48d6f-c897-4a81-917c-92cb52140311 bp-b624898f-b8fc-4215-bcab-4a0712140311 bp-5a7d8cc7-51c9-47c6-9ba9-79ea12140311 bp-040f652d-cc0a-48ba-9754-20c042140311 bp-467c2a07-193c-40d3-bef0-3de852140311
Reporter | ||
Comment 1•10 years ago
|
||
I'm using Nightly on mac, crashing in todays and yesterdays builds, no information about further back.
Comment 2•10 years ago
|
||
Could you provide more specific instructions? (a specific wiki page to edit & specific word to search for) I just tried to reproduce with https://wiki.mozilla.org/index.php?title=Platform&action=edit and the word "vidyo" (which occurs once on the page), and I didn't crash. (using latest Linux nightly, datestamp 2014-3-11)
Reporter | ||
Comment 3•10 years ago
|
||
str |
I can't reproduce on that page, but this works: 1, load https://wiki.mozilla.org/index.php?title=Releases/Firefox_28.0/BuildNotes&action=edit 2, cmd-f to search for mock 3, click on 'Page' to switch back to actual page 4, cmd-g once to crash Or use the 'Show Preview' button at 3 and cmd-g twice to crash. Reloading with cmd-r at 3 doesn't crash.
Comment 4•10 years ago
|
||
With the STR in comment 3 I'm crashing on this line (on Linux): http://hg.mozilla.org/mozilla-central/annotate/69fbe69ddb8c/layout/generic/nsGfxScrollFrame.cpp#l2089 which was added Feb 28, 2014 in bug 968647 part 1 (so I'm guessing it's a regression from that bug).
Blocks: 968647
status-firefox30:
--- → affected
tracking-firefox30:
--- → ?
Keywords: regression
OS: Mac OS X → All
Updated•10 years ago
|
Assignee | ||
Comment 6•10 years ago
|
||
Assignee | ||
Comment 7•10 years ago
|
||
Comment on attachment 8392072 [details] [diff] [review] fix w/ test This is regression by bug 968647. Type ahead find seems to cache old pres shell, so docshell is null. Since any 3rd party addon may cache pres shell, I add null check in ScrollToImpl for more safety.
Attachment #8392072 -
Flags: review?(roc)
Attachment #8392072 -
Flags: review?(roc) → review+
Assignee | ||
Comment 8•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/07050b85efab
Target Milestone: --- → mozilla31
https://hg.mozilla.org/mozilla-central/rev/07050b85efab
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 10•10 years ago
|
||
Reproduced in Nightly 2014-03-11, Win 7 x64. Verified fixed Nightly 31.0a1 (2014-03-19).
Status: RESOLVED → VERIFIED
status-firefox31:
--- → verified
Assignee | ||
Comment 11•10 years ago
|
||
Comment on attachment 8392072 [details] [diff] [review] fix w/ test [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 968647 User impact if declined: When user uses find menu, Firefox may crash after navigating to other page. Testing completed (on m-c, etc.): landed in m-c. And test case is comment #0. Also, I added mochitest for this. Risk to taking this patch (and alternatives if risky): Added nullptr check only. So low risk. String or IDL/UUID changes made by this patch: No
Attachment #8392072 -
Flags: approval-mozilla-aurora?
Updated•10 years ago
|
Attachment #8392072 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 13•10 years ago
|
||
Reproduced with Nightly from 2014-03-11 with STR from comment 3. Verified as fixed on Firefox 30 beta 1 (Build Id: 20140428174145) on Mac OS X 10.8.5, Windows 7 x64 and Ubuntu 13.10 x32: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0) Gecko/20100101 Firefox/30.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Firefox/30.0
Keywords: verifyme
Comment 14•10 years ago
|
||
Why does this test need Timer.jsm, exactly? That causes it to try to clobber the default setTimeout/clearTimeout on the global...
Flags: needinfo?(m_kato)
Assignee | ||
Comment 15•10 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #14) > Why does this test need Timer.jsm, exactly? That causes it to try to > clobber the default setTimeout/clearTimeout on the global... Because I need timer. Ah, I will change it to Components.utils.import("resource://gre/modules/Timer.jsm", xxxx);
Flags: needinfo?(m_kato)
Comment 16•10 years ago
|
||
> Because I need timer.
the test runs in a window. So it has timers already...
Assignee | ||
Comment 17•10 years ago
|
||
Attachment #8428447 -
Flags: review?(bzbarsky)
Comment 18•10 years ago
|
||
Comment on attachment 8428447 [details] [diff] [review] Remove importing Timer.jsm r=me
Attachment #8428447 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 19•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/4c51574053d6
Comment 20•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/4c51574053d6
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•