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.
content: ' appended string';
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
Firefox crashes on second click
The <select> should open to display options. And I guess the CSS property 'content' should be ignored (at least this is Chrome's behavior)
Created attachment 521457 [details]
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)
#1 0x00007ffff6eae205 in gfxContext::gfxContext (this=0x7fffddc5a2b0, surface=0x0)
#2 0x00007ffff6a781ad in nsWindow::OnExposeEvent (this=0x7fffe2d0cef0, aWidget=
#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.
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.
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?
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 ?
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.
This linux crash looks like its due to the widget getting destroyed during WILL_PAINT.
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).
#0 nsWindow::Destroy (this=0x7fffb5a04c40)
#1 0x00007ffff551433d in nsView::DestroyWidget (this=0x7fff989837e0)
#2 0x00007ffff55141bd in nsView::~nsView (this=0x7fff989837e0,
__in_chrg=<value optimized out>)
#3 0x00007ffff55144b4 in nsIView::Destroy (this=0x7fff989837e0)
#4 0x00007ffff4f2bef5 in nsFrame::DestroyFrom (this=0x7fffc52f3d40,
#5 0x00007ffff4fbab79 in nsSplittableFrame::DestroyFrom (
#6 0x00007ffff4f2408a in nsContainerFrame::DestroyFrom (this=0x7fffc52f3d40,
#7 0x00007ffff4f531cb in nsHTMLScrollFrame::DestroyFrom (
#8 0x00007ffff4eef1f5 in nsListControlFrame::DestroyFrom (
#9 0x00007ffff4f486f5 in nsFrameList::DestroyFramesFrom (
#10 0x00007ffff4ed73d3 in nsComboboxControlFrame::DestroyFrom (
#11 0x00007ffff4e2a3c4 in nsIFrame::Destroy (this=0x7fffc52f3898)
#12 0x00007ffff4f10022 in nsBlockFrame::DoRemoveFrame (this=0x7fffc52f34e0,
#13 0x00007ffff4f0e064 in nsBlockFrame::RemoveFrame (this=0x7fffc52f34e0,
#14 0x00007ffff4e778fe in nsFrameManager::RemoveFrame (this=0x7fffc5109438,
#15 0x00007ffff4e1e808 in nsCSSFrameConstructor::ContentRemoved (
this=0x7fffc5109c00, aContainer=0x7fffd3d0d780, aChild=0x7fffc62ca2f0,
#16 0x00007ffff4e22b79 in nsCSSFrameConstructor::RecreateFramesForContent (
this=0x7fffc5109c00, aContent=0x7fffc62ca2f0, aAsyncInsert=0)
#17 0x00007ffff4e1f6df in nsCSSFrameConstructor::ProcessRestyledFrames (
#18 0x00007ffff4e1fada in nsCSSFrameConstructor::RestyleElement (
#19 0x00007ffff4e0ae19 in mozilla::css::RestyleTracker::ProcessOneRestyle (
#20 0x00007ffff4e0a282 in mozilla::css::RestyleTracker::ProcessRestyles (
#21 0x00007ffff4e27b65 in nsCSSFrameConstructor::ProcessPendingRestyles (
#22 0x00007ffff4eac72f in PresShell::FlushPendingNotifications (
#23 0x00007ffff4eb55a9 in PresShell::WillPaint (this=0x7fffc5109400,
#24 0x00007ffff551c7c7 in nsViewManager::CallWillPaintOnObservers (
#25 0x00007ffff551a59a in nsViewManager::DispatchEvent (this=0x7fffc62ba5f0,
aEvent=0x7fffffffc230, aView=0x7fff989837e0, aStatus=0x7fffffffc0a4)
#26 0x00007ffff55138e0 in HandleEvent (aEvent=0x7fffffffc230)
#27 0x00007ffff5fc6c00 in nsWindow::DispatchEvent (this=0x7fffb5a04c40,
#28 0x00007ffff5fca760 in nsWindow::OnExposeEvent (this=0x7fffb5a04c40,
(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.)
Oh, OK. Both the event and the expose_event_cb hold a reference.
Created attachment 522267 [details] [diff] [review]
check for destroy during WILL_PAINT
*** Bug 646952 has been marked as a duplicate of this bug. ***