dom.send_after_paint_to_content pref behaving incorrectly.

RESOLVED WONTFIX

Status

()

Core
Layout: View Rendering
RESOLVED WONTFIX
5 years ago
4 years ago

People

(Reporter: Optimizer, Assigned: mattwoodrow)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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.

STR:

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

Comment 1

5 years ago
Can someone please confirm or look into this ?
(Assignee)

Updated

4 years ago
Assignee: nobody → matt.woodrow
(Assignee)

Comment 2

4 years ago
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.

Test:

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

Comment 3

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

Comment 4

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

Comment 5

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

Comment 6

4 years ago
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 ?
(Assignee)

Comment 7

4 years ago
Drawing into the timeline will results in a paint event for the content, but it should have an empty |event.rects|
(Reporter)

Comment 8

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

Comment 9

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

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.