Closed
Bug 296838
Opened 19 years ago
Closed 19 years ago
drawWindow() doesn't draw elements with position: fixed;
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: ted, Assigned: roc)
Details
Attachments
(6 files)
180 bytes,
text/html
|
Details | |
526 bytes,
text/html
|
Details | |
998 bytes,
text/html
|
Details | |
33.79 KB,
image/png
|
Details | |
32.54 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
chofmann
:
approval1.8b3+
|
Details | Diff | Splinter Review |
32.58 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
asa
:
approval1.8b4+
|
Details | Diff | Splinter Review |
This was found viewing this website: http://www.brentanos.fr/ (a terrible mess of html). Testcase in a sec.
Reporter | ||
Comment 1•19 years ago
|
||
HTML using position: fixed
Reporter | ||
Comment 2•19 years ago
|
||
This example uses the previous attachment in an iframe and attempts to render it to a canvas. It uses enablePrivilege('UniversalBrowserRead').
Reporter | ||
Comment 3•19 years ago
|
||
Strangely enough, it works if the fixed content is inside an iframe in the window you're trying to draw.
Comment 4•19 years ago
|
||
I see both rects in all testcase. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050606 Firefox/1.0+
Reporter | ||
Comment 5•19 years ago
|
||
To clarify, in these testcases, what you should see is two identical images,
with a red rectangle overlapping a green rectangle. If you see a large blank
space on the left side, then the canvas isn't working right. If you see just a
green rectangle on the left side, then drawWindow() isn't working right.
Attached is an image of incorrect rendering on the first testcase (attachment
185477 [details]).
Assignee | ||
Comment 6•19 years ago
|
||
This is quite tough to fix. Suppose you have a document with "position:fixed" elements, and you scroll down. Then you call drawWindow. What should you get? An image of the document as it would be if it was scrolled to the top? Or an image of the document scrolled down?
Assignee | ||
Comment 7•19 years ago
|
||
I'll make it so that you get the whole document, but with the fixed elements at the position in the document where they appear visually. So if you've scrolled down, the fixed elements appear down the document. I have a handle on fixing this, it's just a *little* more complicated than I expected. I'll post a patch on Monday.
Assignee | ||
Comment 8•19 years ago
|
||
This fixes the problem. It's a matter of making sure scrollbars on the root view aren't rendered, and that the root scrollable view is not used to clip any views. We also adjust the rectangle used for rendering to compensate for the amount the viewport is scrolled, and translate the rendered output to the correct position.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attachment #186772 -
Flags: superreview?(dbaron)
Attachment #186772 -
Flags: review?(dbaron)
Comment on attachment 186772 [details] [diff] [review] fix rubber-stamp r+sr=dbaron, although aSuppressClip, aSuppressScrolling, and suppressScrolling seem like odd names for views (they sound like booleans).
Attachment #186772 -
Flags: superreview?(dbaron)
Attachment #186772 -
Flags: superreview+
Attachment #186772 -
Flags: review?(dbaron)
Attachment #186772 -
Flags: review+
Assignee | ||
Comment 10•19 years ago
|
||
Comment on attachment 186772 [details] [diff] [review] fix fixes a significant drawWindow issue, very low risk to non-drawWindow users
Attachment #186772 -
Flags: approval1.8b3?
Comment 11•19 years ago
|
||
Comment on attachment 186772 [details] [diff] [review] fix a=chofmann
Attachment #186772 -
Flags: approval1.8b3? → approval1.8b3+
Assignee | ||
Comment 12•19 years ago
|
||
checked in
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 13•19 years ago
|
||
This seems to have increased Tp on btek by about 4 to 5 ms.
Assignee | ||
Comment 14•19 years ago
|
||
why do you say that?
Assignee | ||
Comment 15•19 years ago
|
||
oops, sorry, I was looking at the wrong thing
Assignee | ||
Comment 16•19 years ago
|
||
This might ameliorate the Tp effect. The patch changed our behaviour on the regular rendering paths from passing aTopView to GetClippedRect() to passing null. This changes it back to passing aTopView. I can't see why that would have much Tp effect; aTopView is usually the topmost view, no parent or zparent, so nothing extra really happens in ApplyClipRect. When aTopView is not the topmost view, it's almost always a popup, so we usually break out of the loop around the same time. But I can't see any other possibility for the slowdown. The weird thing is that before the offscreen rendering stuff landed a few months ago, the loop condition in ApplyClipRect was PR_TRUE --- the same behaviour that we get now passing null. So that checkin would have sped us up by this amount. I think stopping at aTopView is correct though.
Attachment #187093 -
Flags: superreview?(dbaron)
Attachment #187093 -
Flags: review?(dbaron)
Comment on attachment 187093 [details] [diff] [review] fix #2 Rubber-stamp r+sr=dbaron; sorry for the delay.
Attachment #187093 -
Flags: superreview?(dbaron)
Attachment #187093 -
Flags: superreview+
Attachment #187093 -
Flags: review?(dbaron)
Attachment #187093 -
Flags: review+
Assignee | ||
Comment 18•19 years ago
|
||
Comment on attachment 187093 [details] [diff] [review] fix #2 fixes drawWindow bug, something that was already approved, but this has some slight changes to reduce Tp impact (hopefully).
Attachment #187093 -
Flags: approval1.8b4?
Updated•19 years ago
|
Attachment #187093 -
Flags: approval1.8b4? → approval1.8b4+
Assignee | ||
Comment 19•19 years ago
|
||
checked in
You need to log in
before you can comment on or make changes to this bug.
Description
•