Last Comment Bug 829330 - dom.send_after_paint_to_content pref behaving incorrectly.
: dom.send_after_paint_to_content pref behaving incorrectly.
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: unspecified
: x86_64 Windows 7
-- normal (vote)
: ---
Assigned To: Matt Woodrow (:mattwoodrow)
: Jet Villegas (:jet)
Depends on:
  Show dependency treegraph
Reported: 2013-01-10 15:05 PST by Girish Sharma [:Optimizer]
Modified: 2013-03-11 16:18 PDT (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Girish Sharma [:Optimizer] 2013-01-10 15:05:54 PST
when this pref is set to true, the content window should get MozAfterPaint events only related to that content window.

But from some time, I am seeing that *all* the MozAfterPaint events gets forwarded to all the content window.


1) set dom.send_after_paint_to_content to true.
2) Run this JS code in Scratchpad with Browser Context:
window.content.addEventListener("MozAfterPaint", function() Components.utils.reportError("asd"), false);

3) mouse over the tabs bar and see the error message appearing on the error console
Comment 1 User image Girish Sharma [:Optimizer] 2013-01-21 22:19:25 PST
Can someone please confirm or look into this ?
Comment 2 User image Matt Woodrow (:mattwoodrow) 2013-03-10 22:03:31 PDT
I'm not sure this is a valid test, the |window| object for the Scratchpad appears to be the same as the |window| object for my main browser window.


1) Open Web Console
2) Enter 'window.hi = function() { alert("hi"); }'
3) Open Scratchpad
4) Enter 'window.hi()', and run
5) See alert in main browser window.

So, the MozAfterPaint events would be expected behaviour in this case.

Are you seeing this in other cases?
Comment 3 User image Girish Sharma [:Optimizer] 2013-03-10 22:11:11 PDT
my event listener is on the content, not the window. So its the window object for the web page, not the browser.

Also, I came to know of this regression through the Timeline add-on, which used to switch this pref on to show the paint events corresponding to a particular web page only. Then one day, it was showing paint events at 60fps, even if there was no paint happening on the website.

try this : if you do window.content.alert("ji") in scratchpad, it will show up as content alert.
Comment 4 User image Matt Woodrow (:mattwoodrow) 2013-03-10 22:25:41 PDT
Ah right, sorry, I misunderstood your issue.

Unfortunately this is also expected behaviour since DLBI.

We now compute invalid regions using the layer tree (for the entire browser window), and have no way to determine which subdocument they belong to.

So we only send the changed region to the root window, and send an empty MozAfterPaint event to all child documents.
Comment 5 User image Matt Woodrow (:mattwoodrow) 2013-03-10 22:32:21 PDT
Actually, we do compute the changed region for the root content document. But not subdocuments (like within an iframe).

You need chrome privileges though (because the region might give you information about what is changing within a different-origin iframe).

If you can get those, then you should get valid rects passed to the paint listener when the content area changes, and no rects passed when the UI changes.
Comment 6 User image Girish Sharma [:Optimizer] 2013-03-10 22:50:04 PDT
I have chrome privileges. The problem is that, the Graphical Timeline of Events use to show paint events too (along with other event types like mouse, keyboard etc). But since this issue, the paint events are just coming as soon as they can, because : When a paint event comes, I draw that on the canvas of Timeline, which in turn caused another paint event to appear.

That is why I used to rely on this pref, such that drawing anything on timeline would not cause a content paint event to appear and in turn preventing a recursive chain reaction of paint events.

Is there a way to do this now ?
Comment 7 User image Matt Woodrow (:mattwoodrow) 2013-03-10 23:06:53 PDT
Drawing into the timeline will results in a paint event for the content, but it should have an empty |event.rects|
Comment 8 User image Girish Sharma [:Optimizer] 2013-03-10 23:11:15 PDT
So are you suggesting that I skip all events that have |event.rects| empty and thus do not draw for them. This will lead to drawing paint events only for content.

Let me try this and get back to you.
Comment 9 User image Girish Sharma [:Optimizer] 2013-03-11 10:27:30 PDT
Okay, I tried the way you suggested, and it works. If there is no other way to actually fix it, then please go ahead and resolve wontfix this bug.

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