Last Comment Bug 644542 - css rule :after with 'content' property crashes firefox when applied on <select> [@ gfxContext::gfxContext ]
: css rule :after with 'content' property crashes firefox when applied on <sele...
: crash
Product: Core
Classification: Components
Component: Widget: Gtk (show other bugs)
: Trunk
: x86_64 Linux
-- critical (vote)
: mozilla6
Assigned To: Karl Tomlinson (:karlt)
: 646952 (view as bug list)
Depends on:
Blocks: 645634
  Show dependency treegraph
Reported: 2011-03-24 04:16 PDT by PowerKiKi
Modified: 2012-12-04 23:36 PST (History)
7 users (show)
karlt: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

HTML testcase (635 bytes, text/html)
2011-03-24 04:16 PDT, PowerKiKi
no flags Details
check for destroy during WILL_PAINT (1.01 KB, patch)
2011-03-27 19:19 PDT, Karl Tomlinson (:karlt)
roc: review+
Details | Diff | Splinter Review

Description User image PowerKiKi 2011-03-24 04:16:06 PDT
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.2a1pre) Gecko/20110323 Firefox/4.2a1pre
Build Identifier: Minefield 4.2a1pre (2011-03-23)

The CSS rule :after with the property 'content' will crash Firefox when applied on <select> element and user click twice on it.

guilty CSS:

    select:after {
	    content: ' appended string';

Reproducible: Always

Steps to Reproduce:
1. open attached HTML page
2. click once on <select> to "open" it (nothing happens, it does not open)
3. click a second time, firefox crash
Actual Results:  
Firefox crashes on second click

Expected Results:  
The <select> should open to display options. And I guess the CSS property 'content' should be ignored (at least this is Chrome's behavior)
Comment 1 User image PowerKiKi 2011-03-24 04:16:57 PDT
Created attachment 521457 [details]
HTML testcase
Comment 2 User image PowerKiKi 2011-03-24 04:20:25 PDT
This was also reproduced on Ubuntu (FF4.0) and OSX (FF4.0rc1).
Comment 3 User image Boris Zbarsky [:bz] (still a bit busy) 2011-03-24 11:46:02 PDT
> nothing happens, it does not open

That's a known bug.

For the rest, I can't reproduce this crash on Mac.  Do you have a crash incident id for it (from about:crashes)?

I eventually got it to crash on Linux after a lot of clicking, with this error:

(firefox-bin:25991): Gdk-CRITICAL **: gdk_window_peek_children: assertion `GDK_IS_WINDOW (window)' failed

followed by gfxContext::gfxContext being called on a null surface, which is what crashed).  Looks like that last bit happened because in widget/src/gtk2/nsWindow.cpp nsWindow::GetThebesSurface() returned null because it has no mGdkWindow.  We should certainly fix that.

Full stack to the crash is:

#0  0x00007ffff5aea6fc in gfxASurface::CairoSurface (this=0x0)
    at ../../dist/include/gfxASurface.h:118
#1  0x00007ffff6eae205 in gfxContext::gfxContext (this=0x7fffddc5a2b0, surface=0x0)
    at ../../../mozilla/gfx/thebes/gfxContext.cpp:64
#2  0x00007ffff6a781ad in nsWindow::OnExposeEvent (this=0x7fffe2d0cef0, aWidget=
    0x7fffe57d8000, aEvent=0x7fffffffcd00)
    at ../../../../mozilla/widget/src/gtk2/nsWindow.cpp:2189
#3  0x00007ffff6a813de in expose_event_cb (widget=0x7fffe57d8000, event=
    0x7fffffffcd00) at ../../../../mozilla/widget/src/gtk2/nsWindow.cpp:5507

and then we're into the gtk event loop.
Comment 4 User image PowerKiKi 2011-03-26 06:42:35 PDT
Here is the related crash report:

As of the OSX crash, that was on my colleague laptop, but not the last OS version but 10.6.3. I'll ask him for a crash report ID.

I'm new to bug reporting for Firefox, so just let me know if there is anything I could help with.
Comment 5 User image PowerKiKi 2011-03-26 07:03:12 PDT
And that's the crash report on OSX:

PS: I don't understand why the crash reports already have related bugs which are fixed. How crash reports and bugs are related ?
Comment 6 User image Boris Zbarsky [:bz] (still a bit busy) 2011-03-26 07:27:34 PDT
OK, your Linux crash is what I saw on my end.

The mac crash looks like a crash due to mDropdownFrame->GetView() being null in nsComboboxControlFrame::ShowPopup (?).  I have no idea how that can possibly happen, especially when we just did a resize call on the view and it was ok.  Maybe some other view is null; I don't quite see how we land in GetFirstChild from ShowPopup's call to SetViewVisibility.   roc?

> let me know if there is anything I could help with.

Figuring out how to reliably reproduce on Mac would be the only thing, I think...

> How crash reports and bugs are related ?

Just by the name of the function the crash happens in.  So all you're seeing is that we used to have other crashes in the same function.

We should definitely fix the Linux widget issue here.  Karl, roc, who's a good assignee for that?
Comment 7 User image PowerKiKi 2011-03-26 07:54:36 PDT
For OSX version I can't be of much help, as it was my colleague computer, but I'll ask him to come here. From what he told me it is reproducible every time, exactly as it is for me on Linux. So I expected it to be the same bug. But from what you say it maybe something different.

I also tried on Win7 and FF4.0. It does not crash, but the <select> element never opens. I have no idea about the codebase, but my guess is there is something fishy about how the 'content' property is handled for <select> element on all platforms, which ultimately leads to different behaviour/crash.

Should we open new bugs for other platforms behaviours or keep investigating further with this single bug ?
Comment 8 User image PowerKiKi 2011-03-26 08:23:22 PDT
Another colleague of mine tested FF 4.0 on OS X 10.6.5 and it does NOT crash. So that may be OSX version related...
Comment 9 User image Boris Zbarsky [:bz] (still a bit busy) 2011-03-26 08:24:35 PDT
Adrien, there is definitely something fishy.  The fishy bit is bug 464758.

But the crashes are definitely platform-specific; the Linux one is handling in gtk2-specific event handling code.  Filing a separate bug on the Mac crash is a good idea.
Comment 10 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2011-03-27 14:51:42 PDT
(In reply to comment #6)
> The mac crash looks like a crash due to mDropdownFrame->GetView() being null in
> nsComboboxControlFrame::ShowPopup (?).  I have no idea how that can possibly
> happen, especially when we just did a resize call on the view and it was ok. 
> Maybe some other view is null; I don't quite see how we land in GetFirstChild
> from ShowPopup's call to SetViewVisibility.   roc?

I don't understand it either. I think we can't trust that part of the stack.
Comment 11 User image Karl Tomlinson (:karlt) 2011-03-27 18:44:18 PDT
This linux crash looks like its due to the widget getting destroyed during WILL_PAINT.
Comment 12 User image Boris Zbarsky [:bz] (still a bit busy) 2011-03-27 18:46:14 PDT
Hmm.  WILL_PAINT might be calling into PresShell::WillPaint?  If so, it can basically run arbitrary script (and can _definitely_ trigger arbitrary views and widgets getting destroyed).
Comment 13 User image Karl Tomlinson (:karlt) 2011-03-27 19:12:53 PDT

#0  nsWindow::Destroy (this=0x7fffb5a04c40)
    at /home/karl/moz/dev/widget/src/gtk2/nsWindow.cpp:828
#1  0x00007ffff551433d in nsView::DestroyWidget (this=0x7fff989837e0)
    at /home/karl/moz/dev/view/src/nsView.cpp:301
#2  0x00007ffff55141bd in nsView::~nsView (this=0x7fff989837e0, 
    __in_chrg=<value optimized out>)
    at /home/karl/moz/dev/view/src/nsView.cpp:272
#3  0x00007ffff55144b4 in nsIView::Destroy (this=0x7fff989837e0)
    at /home/karl/moz/dev/view/src/nsView.cpp:344
#4  0x00007ffff4f2bef5 in nsFrame::DestroyFrom (this=0x7fffc52f3d40, 
    at /home/karl/moz/dev/layout/generic/nsFrame.cpp:462
#5  0x00007ffff4fbab79 in nsSplittableFrame::DestroyFrom (
    this=0x7fffc52f3d40, aDestructRoot=0x7fffc52f3898)
    at /home/karl/moz/dev/layout/generic/nsSplittableFrame.cpp:75
#6  0x00007ffff4f2408a in nsContainerFrame::DestroyFrom (this=0x7fffc52f3d40, 
    at /home/karl/moz/dev/layout/generic/nsContainerFrame.cpp:292
#7  0x00007ffff4f531cb in nsHTMLScrollFrame::DestroyFrom (
    this=0x7fffc52f3d40, aDestructRoot=0x7fffc52f3898)
    at /home/karl/moz/dev/layout/generic/nsGfxScrollFrame.cpp:124
#8  0x00007ffff4eef1f5 in nsListControlFrame::DestroyFrom (
    this=0x7fffc52f3d40, aDestructRoot=0x7fffc52f3898)
    at /home/karl/moz/dev/layout/forms/nsListControlFrame.cpp:220
#9  0x00007ffff4f486f5 in nsFrameList::DestroyFramesFrom (
    this=0x7fffc52f3980, aDestructRoot=0x7fffc52f3898)
    at /home/karl/moz/dev/layout/generic/nsFrameList.cpp:98
#10 0x00007ffff4ed73d3 in nsComboboxControlFrame::DestroyFrom (
    this=0x7fffc52f3898, aDestructRoot=0x7fffc52f3898)
    at /home/karl/moz/dev/layout/forms/nsComboboxControlFrame.cpp:1241
#11 0x00007ffff4e2a3c4 in nsIFrame::Destroy (this=0x7fffc52f3898)
    at /home/karl/moz/dev/layout/base/../generic/nsIFrame.h:556
#12 0x00007ffff4f10022 in nsBlockFrame::DoRemoveFrame (this=0x7fffc52f34e0, 
    aDeletedFrame=0x7fffc52f3898, aFlags=2)
    at /home/karl/moz/dev/layout/generic/nsBlockFrame.cpp:5432
#13 0x00007ffff4f0e064 in nsBlockFrame::RemoveFrame (this=0x7fffc52f34e0, 
    aListName=0x0, aOldFrame=0x7fffc52f3898)
    at /home/karl/moz/dev/layout/generic/nsBlockFrame.cpp:5001
#14 0x00007ffff4e778fe in nsFrameManager::RemoveFrame (this=0x7fffc5109438, 
    aListName=0x0, aOldFrame=0x7fffc52f3898)
    at /home/karl/moz/dev/layout/base/nsFrameManager.cpp:512
#15 0x00007ffff4e1e808 in nsCSSFrameConstructor::ContentRemoved (
    this=0x7fffc5109c00, aContainer=0x7fffd3d0d780, aChild=0x7fffc62ca2f0, 
    at /home/karl/moz/dev/layout/base/nsCSSFrameConstructor.cpp:7544
#16 0x00007ffff4e22b79 in nsCSSFrameConstructor::RecreateFramesForContent (
    this=0x7fffc5109c00, aContent=0x7fffc62ca2f0, aAsyncInsert=0)
    at /home/karl/moz/dev/layout/base/nsCSSFrameConstructor.cpp:9145
#17 0x00007ffff4e1f6df in nsCSSFrameConstructor::ProcessRestyledFrames (
    this=0x7fffc5109c00, aChangeList=...)
    at /home/karl/moz/dev/layout/base/nsCSSFrameConstructor.cpp:7998
#18 0x00007ffff4e1fada in nsCSSFrameConstructor::RestyleElement (
    this=0x7fffc5109c00, aElement=0x7fffc62ca2f0, 
    aPrimaryFrame=0x7fffc52f3898, aMinHint=nsChangeHint_RepaintFrame, 
    aRestyleTracker=..., aRestyleDescendants=1)
    at /home/karl/moz/dev/layout/base/nsCSSFrameConstructor.cpp:8084
#19 0x00007ffff4e0ae19 in mozilla::css::RestyleTracker::ProcessOneRestyle (
    this=0x7fffc5109c98, aElement=0x7fffc62ca2f0, 
    aRestyleHint=eRestyle_Subtree, aChangeHint=nsChangeHint_RepaintFrame)
    at /home/karl/moz/dev/layout/base/RestyleTracker.cpp:156
#20 0x00007ffff4e0a282 in mozilla::css::RestyleTracker::ProcessRestyles (
    at /home/karl/moz/dev/layout/base/RestyleTracker.cpp:240
#21 0x00007ffff4e27b65 in nsCSSFrameConstructor::ProcessPendingRestyles (
    at /home/karl/moz/dev/layout/base/nsCSSFrameConstructor.cpp:11652
#22 0x00007ffff4eac72f in PresShell::FlushPendingNotifications (
    this=0x7fffc5109400, aType=Flush_InterruptibleLayout)
    at /home/karl/moz/dev/layout/base/nsPresShell.cpp:4797
#23 0x00007ffff4eb55a9 in PresShell::WillPaint (this=0x7fffc5109400, 
    at /home/karl/moz/dev/layout/base/nsPresShell.cpp:7409
#24 0x00007ffff551c7c7 in nsViewManager::CallWillPaintOnObservers (
    this=0x7fffc1b57f90, aWillSendDidPaint=1)
    at /home/karl/moz/dev/view/src/nsViewManager.cpp:1673
#25 0x00007ffff551a59a in nsViewManager::DispatchEvent (this=0x7fffc62ba5f0, 
    aEvent=0x7fffffffc230, aView=0x7fff989837e0, aStatus=0x7fffffffc0a4)
    at /home/karl/moz/dev/view/src/nsViewManager.cpp:909
#26 0x00007ffff55138e0 in HandleEvent (aEvent=0x7fffffffc230)
    at /home/karl/moz/dev/view/src/nsView.cpp:161
#27 0x00007ffff5fc6c00 in nsWindow::DispatchEvent (this=0x7fffb5a04c40, 
    aEvent=0x7fffffffc230, aStatus=@0x7fffffffc358)
    at /home/karl/moz/dev/widget/src/gtk2/nsWindow.cpp:696
#28 0x00007ffff5fca760 in nsWindow::OnExposeEvent (this=0x7fffb5a04c40, 
    aWidget=0x7fffb5d25000, aEvent=0x7fffffffca20)
    at /home/karl/moz/dev/widget/src/gtk2/nsWindow.cpp:2243

(The nsView does not have the last reference to the nsIWidget.  I don't know what is holding the 2 references but I doubt we can depend on that.)
Comment 14 User image Karl Tomlinson (:karlt) 2011-03-27 19:17:02 PDT
Oh, OK.  Both the event and the expose_event_cb hold a reference.
Comment 15 User image Karl Tomlinson (:karlt) 2011-03-27 19:19:17 PDT
Created attachment 522267 [details] [diff] [review]
check for destroy during WILL_PAINT
Comment 16 User image Boris Zbarsky [:bz] (still a bit busy) 2011-03-31 13:40:33 PDT
*** Bug 646952 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.