172227 - use of scroll bar on scrolling div makes content unreadable

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Kevin Cook]

The page at http://www.lynuxworks.com/products/lynxos/lynxos07.php3 has a small
navigation menu contained within a scrolling <div> on the right side of the page. 

If you try to use the scroll bar to reveal the hidden content in the <div>, the
content is smeared and unreadable.  Perhaps the content is being drawn on top of
itself as the scrolling takes place.

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

What build ID?

Comment 2

[Kevin Cook]

Oh, this was build 2002100204 on Win 98.

Comment 3

[Mats Palmgren (inactive)]

Attachment: Screenshot

Comment 4

[Mats Palmgren (inactive)]

Confirming bug, 2002-10-02-08 trunk Linux

Comment 5

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

Is this a regression? If so, what's the last known working build?

Could you provide a simplified testcase?

Comment 6

[Kevin Cook]

Yes, it's a regression, which probably happened within the last week, possibly
even in today or yesterday's builds.  I didn't notice the problem while using
that site with the build I downloaded 24 hours earlier, though perhaps it was
already broken and I simply didn't try scrolling one of those menus.

Comment 7

[Mats Palmgren (inactive)]

Also happens when you click "Edit" on a Patch attachment in Bugzilla, e.g.:
http://bugzilla.mozilla.org/attachment.cgi?id=100810&action=edit

Comment 8

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

*** Bug 172548 has been marked as a duplicate of this bug. ***

Comment 9

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

OK, so the problem is that the view sync code made a bogus optimization. When
the NS_FRAME_OUTSIDE_CHILDREN flag gets turned on we need to mark the view
transparent, but we weren't going into the transparency-calculation path at all
unless the view bounds changed and clipping was active --- neither of which
holds in this case. So we need to just disable that bogus optimization. Patch
coming up.

Comment 10

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

Attachment: fix

Comment 11

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 101873 [details] [diff] [review]
fix

r=dbaron, except could you line-wrap this comment at a width less than 80
characters?

>+    // Even if the size hasn't changed, we need to sync up the geometry dependent properties, because
>+    // (kidState & NS_FRAME_OUTSIDE_CHILDREN) might have changed, and we can't detect whether it has
>+    // or not. Likewise, whether the view size has changed or not, we may need to change the transparency
>+    // state even if there is no clip.

Comment 12

[Mats Palmgren (inactive)]

*** Bug 173020 has been marked as a duplicate of this bug. ***

Comment 13

[kinmoz]

Comment on attachment 101873 [details] [diff] [review]
fix

sr=[e-mail] with dbaron's line wrap request ... can you also re-wrap
the 2 pre-existing comment blocks in that same method too?

Comment 14

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

sure, will do. thanks!

Comment 15

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

Fix checked in.

Comment 16

[José Jeria]

Attachment: Testcase

With build 2002123008, Windows XP bug is again visible. See attached testcase
to confirm please.

Comment 17

[José Jeria]

The testcase in duped bug 173020 also shows the black background. The URL:s
attached to this bug does not though.

Can also be seen on
resource:///res/samples/test12.html
make window smaller so scrollbar appears and then scroll --> black background

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

I can see this with Moz20021222/Linux too.

Comment 19

[José Jeria]

FYI:
Bug 187503 was opened for the new issue.