The default bug view has changed. See this FAQ.

css rule :after with 'content' property crashes firefox when applied on <select> [@ gfxContext::gfxContext ]

RESOLVED FIXED in mozilla6

Status

()

Core
Widget: Gtk
--
critical
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: PowerKiKi, Assigned: karlt)

Tracking

(Blocks: 1 bug, {crash})

Trunk
mozilla6
x86_64
Linux
crash
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bugday-2011-05-06], crash signature)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
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)
(Reporter)

Comment 1

6 years ago
Created attachment 521457 [details]
HTML testcase
(Reporter)

Comment 2

6 years ago
This was also reproduced on Ubuntu (FF4.0) and OSX (FF4.0rc1).
> 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.
Component: Style System (CSS) → Widget: Gtk
QA Contact: style-system → gtk
Version: unspecified → Trunk
(Reporter)

Comment 4

6 years ago
Here is the related crash report: https://crash-stats.mozilla.com/report/index/41dd2913-dfe8-45e5-9aa1-c17802110326

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.
(Reporter)

Comment 5

6 years ago
And that's the crash report on OSX: https://crash-stats.mozilla.com/report/index/bd8b7b27-fea2-4619-a6e1-4f7d52110326


PS: I don't understand why the crash reports already have related bugs which are fixed. How crash reports and bugs are related ?
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 7

6 years ago
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 ?
(Reporter)

Comment 8

6 years ago
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...
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.
(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.
(Assignee)

Comment 11

6 years ago
This linux crash looks like its due to the widget getting destroyed during WILL_PAINT.
Assignee: nobody → karlt
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).
(Assignee)

Comment 13

6 years ago
Yes.

#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, 
    aDestructRoot=0x7fffc52f3898)
    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, 
    aDestructRoot=0x7fffc52f3898)
    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, 
    aOldNextSibling=0x7fffc5206880, 
    aFlags=nsCSSFrameConstructor::REMOVE_FOR_RECONSTRUCTION, 
    aDidReconstruct=0x7fffffffac0c)
    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 (
    this=0x7fffc5109c98)
    at /home/karl/moz/dev/layout/base/RestyleTracker.cpp:240
#21 0x00007ffff4e27b65 in nsCSSFrameConstructor::ProcessPendingRestyles (
    this=0x7fffc5109c00)
    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, 
    aWillSendDidPaint=1)
    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.)
(Assignee)

Comment 14

6 years ago
Oh, OK.  Both the event and the expose_event_cb hold a reference.
(Assignee)

Comment 15

6 years ago
Created attachment 522267 [details] [diff] [review]
check for destroy during WILL_PAINT
Attachment #522267 - Flags: review?(roc)
Attachment #522267 - Flags: review?(roc) → review+
Blocks: 645634
Duplicate of this bug: 646952

Updated

6 years ago
Keywords: crash
OS: Linux → OpenBSD
Summary: css rule :after with 'content' property crashes firefox when applied on <select> → css rule :after with 'content' property crashes firefox when applied on <select> [@ gfxContext::gfxContext ]
Whiteboard: [bugday-2011-05-06]

Updated

6 years ago
OS: OpenBSD → Linux
(Assignee)

Comment 17

6 years ago
http://hg.mozilla.org/mozilla-central/rev/3865e976d54d
http://hg.mozilla.org/mozilla-central/rev/3833fae240f7
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
Crash Signature: [@ gfxContext::gfxContext ]
You need to log in before you can comment on or make changes to this bug.