620658 - Crash [@ libc-2.11.so + 0x326b5 ] during browser_auth.js on Linux64 mochitest-other debug

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Markus Stange [:mstange]]

This is a completely unhelpful bug report, but I guess filing a placeholder bug is better than not filing anything.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1292926059.1292928491.7893.gz&fulltext=1#err4
Rev3 Fedora 12x64 mozilla-central debug test mochitest-other on 2010/12/21 02:07:39 
s: talos-r3-fed64-031

Crash reason:  SIGABRT
Crash address: 0x1f40000089c

Thread 0 (crashed)
 0  libc-2.11.so + 0x326b5
    rbx = 0x00000400   r12 = 0x0000004d   r13 = 0x374f0c10   r14 = 0x0000008a
    r15 = 0x00000007   rip = 0xd2e326b5   rsp = 0x374f08e8   rbp = 0x374f1330
    Found by: given as instruction pointer in context
 1  libc-2.11.so + 0x33e94
    rip = 0xd2e33e95   rsp = 0x374f08f0
    Found by: stack scanning
 2  libc-2.11.so + 0x13c7b2
    rip = 0xd2f3c7b3   rsp = 0x374f0918
    Found by: stack scanning
 3  libc-2.11.so + 0x13c7b6
    rip = 0xd2f3c7b7   rsp = 0x374f0938
    Found by: stack scanning
 4  libc-2.11.so + 0x13ade3
    rip = 0xd2f3ade4   rsp = 0x374f0958
    Found by: stack scanning
 5  libc-2.11.so + 0x13c7b2
    rip = 0xd2f3c7b3   rsp = 0x374f0968
    Found by: stack scanning
 6  libc-2.11.so + 0x13c7b6
    rip = 0xd2f3c7b7   rsp = 0x374f0988
    Found by: stack scanning

Comment 1

[Legacy TBPL/Treeherder Robot]

mstange%themasta.com
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1292933239.1292935810.13531.gz
Rev3 Fedora 12 mozilla-central debug test mochitest-other on 2010/12/21 04:07:19

s: talos-r3-fed-016
PROCESS-CRASH | Main app process exited normally | application crashed (minidump found)
Thread 0 (crashed)
PROCESS-CRASH | Main app process exited normally | application crashed (minidump found)
Thread 0 (crashed)
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/xpinstall/browser_auth.js | Exited with code 1 during test run
PROCESS-CRASH | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/xpinstall/browser_auth.js | application crashed (minidump found)
Thread 0 (crashed)
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | missing output line for total leaks!

Comment 2

[Markus Stange [:mstange]]

This second occurrence had a much more helpful stack:

Thread 0 (crashed)
 0  linux-gate.so + 0x424
    eip = 0x00455424   esp = 0xbff66e0c   ebp = 0xbff66e24   ebx = 0x0000082b
    esi = 0x00000000   edi = 0x00c58ff4   eax = 0x00000000   ecx = 0x0000082b
    edx = 0x00000006   efl = 0x00000206
    Found by: given as instruction pointer in context
 1  libc-2.11.so + 0x2c349
    eip = 0x00b1434a   esp = 0xbff66e2c   ebp = 0xbff66f4c
    Found by: previous frame's frame pointer
 2  libc-2.11.so + 0x67e5c
    eip = 0x00b4fe5d   esp = 0xbff66f54   ebp = 0xbff67590
    Found by: previous frame's frame pointer
 3  libc-2.11.so + 0x6e260
    eip = 0x00b56261   esp = 0xbff67598   ebp = 0xbff675c8
    Found by: previous frame's frame pointer
 4  libxul.so!free [nsTraceMalloc.c : 1303 + 0xa]
    eip = 0x02735f1b   esp = 0xbff675d0   ebp = 0xbff675f8
    Found by: previous frame's frame pointer
 5  libmozalloc.so!moz_free [mozalloc.cpp : 92 + 0xa]
    eip = 0x00825fd4   esp = 0xbff67600   ebp = 0xbff67608   ebx = 0x008271f0
    Found by: call frame info
 6  libxul.so!nsWindow::ResizeTransparencyBitmap [mozalloc.h : 265 + 0xa]
    eip = 0x0233209f   esp = 0xbff67610   ebp = 0xbff67668   ebx = 0x0340e678
    Found by: call frame info
 7  libxul.so!nsWindow::NativeResize [nsWindow.cpp : 4310 + 0x18]
    eip = 0x023322c0   esp = 0xbff67670   ebp = 0xbff676a8   ebx = 0x0340e678
    Found by: call frame info
 8  libxul.so!nsWindow::Resize [nsWindow.cpp : 1196 + 0x36]
    eip = 0x02323c28   esp = 0xbff676b0   ebp = 0xbff67708   ebx = 0x0340e678
    Found by: call frame info
 9  libxul.so!nsView::DoResetWidgetBounds [nsView.cpp : 467 + 0x44]
    eip = 0x018dbb27   esp = 0xbff67710   ebp = 0xbff67798   ebx = 0x0340e678
    Found by: call frame info
...
13  libxul.so!nsMenuPopupFrame::LayoutPopup [nsMenuPopupFrame.cpp : 495 + 0x20]
    eip = 0x0152c0fe   esp = 0xbff67830   ebp = 0xbff67908   ebx = 0x0340e678
    esi = 0x00000066   edi = 0x00000004
    Found by: call frame info
...
26  libxul.so!PresShell::DoReflow [nsPresShell.cpp : 7772 + 0x3b]
    eip = 0x012c3ef9   esp = 0xbff68120   ebp = 0xbff68318   ebx = 0x0340e678
    esi = 0x013e8ae8   edi = 0x0000e8f8
    Found by: call frame info
...
34  libxul.so!nsWindow::OnExposeEvent [nsWindow.cpp : 2234 + 0x27]
    eip = 0x02330efb   esp = 0xbff68630   ebp = 0xbff688b8   ebx = 0x0340e678
    esi = 0x00000283   edi = 0x096d0520
    Found by: call frame info
35  libxul.so!expose_event_cb [nsWindow.cpp : 5507 + 0x22]
    eip = 0x02331489   esp = 0xbff688c0   ebp = 0xbff688e8   ebx = 0x04934a88
    esi = 0xbff68a54   edi = 0x096d0520
    Found by: call frame info

We're resizing a transparent window during an expose event. This transparent window is most probably the arrow panel which was restyled in bug 590073.

Dão is going to back out the Linux-specific part of bug 590073.

Comment 3

[Dão Gottwald [:dao]]

Arrow panel style disabled on Linux: http://hg.mozilla.org/mozilla-central/rev/97d9cf2225d6

Comment 5

[Karl Tomlinson (:karlt)]

This seems to indicate some serious memory handling bug.

However, I'll also comment that, as implemented on Linux, these panels have binary 0 or 1 opacity, so "-moz-transition: opacity 300ms;" makes little sense and is likely to slow things down.

Comment 6

[Dão Gottwald [:dao]]

(In reply to comment #5)
> However, I'll also comment that, as implemented on Linux, these panels have
> binary 0 or 1 opacity, so "-moz-transition: opacity 300ms;" makes little sense
> and is likely to slow things down.

Sure, but the patch triggering the crash didn't introduce this, so it's not related to this bug, is it?

Comment 7

[Karl Tomlinson (:karlt)]

Yes, sorry.  The comment is not really related to this bug.

Comment 8

[Dão Gottwald [:dao]]

This bug is holding back theme work.

Comment 9

[Joe Drew (not getting mail)]

In what way is this bug holding back theme work? Theme work required for Firefox 4? Which bugs?

Comment 10

[Dão Gottwald [:dao]]

It prevents us from styling arrow panels (bug 554937) to actually look like arrow panels. A basic arrow panel styling was implemented in bug 590073 and disabled in comment 3.

Comment 11

[Dão Gottwald [:dao]]

Apparently bug 604257 also tracks the arrow panel styling on Linux.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Do we have a way to reproduce this?

Comment 13

[Dão Gottwald [:dao]]

(In reply to comment #12)
> Do we have a way to reproduce this?

Backing out http://hg.mozilla.org/mozilla-central/diff/97d9cf2225d6/toolkit/themes/gnomestripe/global/popup.css and clicking the location bar's identity button in a debug build should do it, I think.

Comment 14

[Karl Tomlinson (:karlt)]

I haven't managed to reproduce in a local debug build based on 2a25c4d1ed99 with 97d9cf2225d6 backed out, with any of the following steps:

1) Click on the location bar's identity button.
2) Same as 1 but with valgrind memcheck (and jemalloc disabled).
3) runtests.py --browser-chrome --test-path=toolkit/mozapps/extensions/test/xpinstall (with and without jemalloc)

Comment 15

[Joe Drew (not getting mail)]

linux-gate.so is, IIRC, usually abort().

I wonder if we're having memory stomped on by something on Dão's (and the tinderbox's) computer, but not on Karl's. What distributions are you using, Karl & Dão?

I think we need to find some form of workaround or fix for this in order to finish the theme work.

Comment 16

[Bill Gianopoulos [:WG9s]]

OK I am unable to duplicate this issue using my own debug or optimized builds.  The difference between my builds and the Official builds, is that the official builds are created using gcc 4.3.3 and I am running gcc version 4.5.1.

So, I think the reason we are running into this crash in libc is that this is a bug in libc that has really long since been fixed.

Comment 17

[Bill Gianopoulos [:WG9s]]

(In reply to comment #16)
> OK I am unable to duplicate this issue using my own debug or optimized builds. 
> The difference between my builds and the Official builds, is that the official
> builds are created using gcc 4.3.3 and I am running gcc version 4.5.1.
> 
> So, I think the reason we are running into this crash in libc is that this is a
> bug in libc that has really long since been fixed.

Further testing seems to confirm this is most likely either a compiler or libc issue and not an issue with Mozilla code.  However, that really brings us no closer to a solution for Firefox 4.

It is way too late in the release process to even consider changing gcc versions :-(

Comment 18

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/e080aa16fae3 might have triggered this again.  I've backed it out, and closed the tree to wait to see if we go green again.

Comment 19

[(no longer active)]

BTW, I don't know why a memory corruption bug which is triggered by some CSS changes is not a hard blocker.  Seems *_really_* scary.

Comment 20

[Mike Beltzner [:beltzner, not reading bugmail]]

I, too, fail to understand why "some CSS rules cause arbitrary crashes on Linux" wouldn't be a hardblocker. And thus!

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Web content can't create transparent widgets, so it can't trigger this bug directly.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Karl, can you try grabbing a tryserver debug build and running it on the Tinderbox VM image?

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Or an opt build I guess

Comment 24

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

So the way to tickle this bug is to uncomment the stuff from comment 3?  It looks like the problems noted from comment 20 on were caused by a bad infra change.

Comment 25

[Dão Gottwald [:dao]]

(In reply to comment #24)
> So the way to tickle this bug is to uncomment the stuff from comment 3?

yes

Comment 26

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(gdb) bt
#0  0x00002b9bfea21ba5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00002b9bfea256b0 in abort () at abort.c:92
#2  0x00002b9bfea5b43b in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x00002b9bfea654b6 in malloc_printerr (action=3, str=0x2b9bfeb39098 "double free or corruption (!prev)", ptr=<value optimized out>) at malloc.c:6283
#4  0x00002b9bfea6bc83 in __libc_free (mem=<value optimized out>) at malloc.c:3738
#5  0x00002b9bf876d5eb in free (ptr=0x2b9c0e4a4b60) at /home/cjones/mozilla/mozilla-central/tools/trace-malloc/lib/nsTraceMalloc.c:1303
#6  0x00002b9bfa93fee4 in moz_free (ptr=0x2b9c0e4a4b60) at /home/cjones/mozilla/mozilla-central/memory/mozalloc/mozalloc.cpp:92
#7  0x00002b9bf83163da in operator delete [] (this=0x2b9c0d1d6c00, aNewWidth=453, aNewHeight=82) at ../../../dist/include/mozilla/mozalloc.h:265
#8  nsWindow::ResizeTransparencyBitmap (this=0x2b9c0d1d6c00, aNewWidth=453, aNewHeight=82) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsWindow.cpp:4702
#9  0x00002b9bf83152e5 in nsWindow::NativeResize (this=0x2b9c0d1d6c00, aX=118, aY=102, aWidth=453, aHeight=82, aRepaint=1) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsWindow.cpp:4349
#10 0x00002b9bf830c6e6 in nsWindow::Resize (this=0x2b9c0d1d6c00, aX=118, aY=102, aWidth=453, aHeight=82, aRepaint=1) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsWindow.cpp:1203
#11 0x00002b9bf785dd79 in nsView::DoResetWidgetBounds (this=0x2b9c0d21b250, aMoveOnly=0, aInvalidateChangedSize=1) at /home/cjones/mozilla/mozilla-central/view/src/nsView.cpp:475
#12 0x00002b9bf785d7cf in nsView::ResetWidgetBounds (this=0x2b9c0d21b250, aRecurse=0, aMoveOnly=0, aInvalidateChangedSize=1) at /home/cjones/mozilla/mozilla-central/view/src/nsView.cpp:374
#13 0x00002b9bf7862147 in nsViewManager::ProcessPendingUpdates (this=0x2b9c0c7b39f0, aView=0x2b9c0d21b250, aDoInvalidate=1) at /home/cjones/mozilla/mozilla-central/view/src/nsViewManager.cpp:464
#14 0x00002b9bf7862172 in nsViewManager::ProcessPendingUpdates (this=0x2b9c0c7b39f0, aView=0x2b9c0c698d00, aDoInvalidate=1) at /home/cjones/mozilla/mozilla-central/view/src/nsViewManager.cpp:470
#15 0x00002b9bf7865562 in nsViewManager::FlushPendingInvalidates (this=0x2b9c0c7b39f0) at /home/cjones/mozilla/mozilla-central/view/src/nsViewManager.cpp:1637
#16 0x00002b9bf78650f9 in nsViewManager::TriggerRefresh (this=0x2b9c0c7b39f0, aUpdateFlags=0) at /home/cjones/mozilla/mozilla-central/view/src/nsViewManager.cpp:1535
#17 0x00002b9bf7865246 in nsViewManager::EndUpdateViewBatch (this=0x2b9c0c7b39f0, aUpdateFlags=0) at /home/cjones/mozilla/mozilla-central/view/src/nsViewManager.cpp:1570
#18 0x00002b9bf7180712 in nsIViewManager::UpdateViewBatch::EndUpdateViewBatch (this=0x7fff0e5d9b50, aUpdateFlags=0) at ../../dist/include/nsIViewManager.h:335
#19 0x00002b9bf78634c3 in nsViewManager::DispatchEvent (this=0x2b9c0c7b39f0, aEvent=0x7fff0e5d9e90, aView=0x2b9c0c698d00, aStatus=0x7fff0e5d9cfc) at /home/cjones/mozilla/mozilla-central/view/src/nsViewManager.cpp:900
#20 0x00002b9bf785c880 in HandleEvent (aEvent=0x7fff0e5d9e90) at /home/cjones/mozilla/mozilla-central/view/src/nsView.cpp:161
#21 0x00002b9bf830ab1e in nsWindow::DispatchEvent (this=0x2b9c0c698d90, aEvent=0x7fff0e5d9e90, aStatus=@0x7fff0e5da078) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsWindow.cpp:571
#22 0x00002b9bf830eccb in nsWindow::OnExposeEvent (this=0x2b9c0c698d90, aWidget=0x1c17e30, aEvent=0x7fff0e5da600) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsWindow.cpp:2241
#23 0x00002b9bf83181a6 in expose_event_cb (widget=0x1c17e30, event=0x7fff0e5da600) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsWindow.cpp:5546
#24 0x00002b9bfb4dd9d8 in _gtk_marshal_BOOLEAN__BOXED (closure=0x2b9c0c630350, return_value=0x7fff0e5da2d0, n_param_values=<value optimized out>, param_values=0x2409ad0, invocation_hint=<value optimized out>, marshal_data=0x2b9bf8318137) at /build/buildd/gtk+2.0-2.22.0/gtk/gtkmarshalers.c:86
#25 0x00002b9bfd1bda6e in g_closure_invoke (closure=0x2b9c0c630350, return_value=0x7fff0e5da2d0, n_param_values=2, param_values=0x2409ad0, invocation_hint=0x7fff0e5da290) at /build/buildd/glib2.0-2.26.0/gobject/gclosure.c:766
#26 0x00002b9bfd1d34d7 in signal_emit_unlocked_R (node=0x1b18a80, detail=<value optimized out>, instance=<value optimized out>, emission_return=<value optimized out>, instance_and_params=<value optimized out>) at /build/buildd/glib2.0-2.26.0/gobject/gsignal.c:3252
#27 0x00002b9bfd1d47db in g_signal_emit_valist (instance=0x1c17e30, signal_id=<value optimized out>, detail=0, var_args=0x7fff0e5da480) at /build/buildd/glib2.0-2.26.0/gobject/gsignal.c:2993
#28 0x00002b9bfd1d4f53 in g_signal_emit (instance=0x6455, signal_id=25685, detail=6) at /build/buildd/glib2.0-2.26.0/gobject/gsignal.c:3040
#29 0x00002b9bfb5f66df in gtk_widget_event_internal (widget=0x1c17e30, event=0x7fff0e5da600) at /build/buildd/gtk+2.0-2.22.0/gtk/gtkwidget.c:4985
#30 0x00002b9bfb4d70d1 in IA__gtk_main_do_event (event=0x7fff0e5da600) at /build/buildd/gtk+2.0-2.22.0/gtk/gtkmain.c:1601
#31 0x00002b9bfc6169da in _gdk_window_process_updates_recurse (window=0x1b05360, expose_region=0x22b1580) at /build/buildd/gtk+2.0-2.22.0/gdk/gdkwindow.c:5424
#32 0x00002b9bfc61346b in gdk_window_process_updates_internal (window=0x1b05360) at /build/buildd/gtk+2.0-2.22.0/gdk/gdkwindow.c:5583
#33 0x00002b9bfc6152e1 in IA__gdk_window_process_all_updates () at /build/buildd/gtk+2.0-2.22.0/gdk/gdkwindow.c:5691
#34 0x00002b9bfc615349 in gdk_window_update_idle (data=0x6455) at /build/buildd/gtk+2.0-2.22.0/gdk/gdkwindow.c:5317
#35 0x00002b9bfc5f0626 in gdk_threads_dispatch (data=0x2b9c0c49b2c0) at /build/buildd/gtk+2.0-2.22.0/gdk/gdk.c:512
#36 0x00002b9bfdc75342 in g_main_dispatch (context=0x1b08c10) at /build/buildd/glib2.0-2.26.0/glib/gmain.c:2149
#37 g_main_context_dispatch (context=0x1b08c10) at /build/buildd/glib2.0-2.26.0/glib/gmain.c:2702
#38 0x00002b9bfdc792a8 in g_main_context_iterate (context=0x1b08c10, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at /build/buildd/glib2.0-2.26.0/glib/gmain.c:2780
#39 0x00002b9bfdc7945c in g_main_context_iteration (context=0x1b08c10, may_block=0) at /build/buildd/glib2.0-2.26.0/glib/gmain.c:2843
#40 0x00002b9bf831d6ba in nsAppShell::ProcessNextNativeEvent (this=0x2b9c0c013f00, mayWait=0) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsAppShell.cpp:144
#41 0x00002b9bf8346b53 in nsBaseAppShell::DoProcessNextNativeEvent (this=0x2b9c0c013f00, mayWait=0) at /home/cjones/mozilla/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:176
#42 0x00002b9bf8346eed in nsBaseAppShell::OnProcessNextEvent (this=0x2b9c0c013f00, thr=0x2b9c0c000e30, mayWait=0, recursionDepth=0) at /home/cjones/mozilla/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:318
#43 0x00002b9bf8733958 in nsThread::ProcessNextEvent (this=0x2b9c0c000e30, mayWait=0, result=0x7fff0e5daa2c) at /home/cjones/mozilla/mozilla-central/xpcom/threads/nsThread.cpp:597
#44 0x00002b9bf86c0ad8 in NS_ProcessNextEvent_P (thread=0x2b9c0c000e30, mayWait=0) at nsThreadUtils.cpp:250
#45 0x00002b9bf84d159c in mozilla::ipc::MessagePump::Run (this=0x1b95f10, aDelegate=0x1b95fa0) at /home/cjones/mozilla/mozilla-central/ipc/glue/MessagePump.cpp:110
#46 0x00002b9bf87a629d in MessageLoop::RunInternal (this=0x1b95fa0) at /home/cjones/mozilla/mozilla-central/ipc/chromium/src/base/message_loop.cc:219
#47 0x00002b9bf87a6222 in MessageLoop::RunHandler (this=0x1b95fa0) at /home/cjones/mozilla/mozilla-central/ipc/chromium/src/base/message_loop.cc:202
#48 0x00002b9bf87a61b3 in MessageLoop::Run (this=0x1b95fa0) at /home/cjones/mozilla/mozilla-central/ipc/chromium/src/base/message_loop.cc:176
#49 0x00002b9bf8346bdf in nsBaseAppShell::Run (this=0x2b9c0c013f00) at /home/cjones/mozilla/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:195
#50 0x00002b9bf805f84b in nsAppStartup::Run (this=0x1c396c0) at /home/cjones/mozilla/mozilla-central/toolkit/components/startup/src/nsAppStartup.cpp:218
#51 0x00002b9bf6e8f4a1 in XRE_main (argc=4, argv=0x7fff0e5db4f8, aAppData=0x1ac7a30) at /home/cjones/mozilla/mozilla-central/toolkit/xre/nsAppRunner.cpp:3787
#52 0x0000000000401272 in main (argc=5, argv=0x7fff0e5db4f8) at /home/cjones/mozilla/mozilla-central/browser/app/nsBrowserApp.cpp:158

Comment 27

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

The problem is that during the dispatch of NS_PAINT, the gtk2 nsWindow bounds change (shrink), and we try to update the alpha mask for an incorrectly-sized rect.  It looks like we have two options for fixing the bug

 - dispatch NS_WILL_PAINT immediately on entering OnExposeEvent, then clip the expose area to mBounds after that dispatch.
 - in UpdateTranslucentWindowAlphaInternal(), clip aRect to mBounds.

I'm not sure which is preferable; not sure which would be less glitchy gfx-wise.

Comment 28

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Add nsRegion::Contains(nsRegion)

Comment 29

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Dispatch WILL_PAINT before PAINT to allow scripts etc. to run, which may change the window bounds

Depends on part in bug 627273, but that's ready to land at any time.

Comment 30

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

*part 2.

Comment 31

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Reversion of theme changes, in case anyone finds it useful

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+        // XXX this lies when we're using GL compositing

I think you need to fix this now, because it'll start to matter now that we're firing WILL_PAINT.

Also, please don't change these assertions to ABORT_IF_FALSE. That's just unnecessary crashy-crashy.

Comment 33

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Dispatch WILL_PAINT before PAINT to allow scripts etc. to run, which may change the window bounds. v2

(In reply to comment #32)
> +        // XXX this lies when we're using GL compositing
> 
> I think you need to fix this now, because it'll start to matter now that we're
> firing WILL_PAINT.
> 

OK.

> Also, please don't change these assertions to ABORT_IF_FALSE. That's just
> unnecessary crashy-crashy.

Shrug, OK.  We know that we get crashy-crashy when the old one fails.  The new one is uninteresting right now so I dropped it.

Comment 34

[Karl Tomlinson (:karlt)]

Comment on attachment 506993 [details] [diff] [review]
Dispatch WILL_PAINT before PAINT to allow scripts etc. to run, which may change the window bounds. v2

>     nsPaintEvent event(PR_TRUE, NS_PAINT, this);
>     event.refPoint.x = aEvent->area.x;
>     event.refPoint.y = aEvent->area.y;
>-    event.willSendDidPaint = PR_TRUE;

Leave this in.  r+ on the rest.

Comment 35

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

http://hg.mozilla.org/mozilla-central/rev/23cfa8965c9e
http://hg.mozilla.org/mozilla-central/rev/0f592a972482

Dão, I assume you'll re-land the CSS changes in another bug.