Dynamic use of the clip property is causing repaint problems.

VERIFIED FIXED in M17

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Shashi Narain, Assigned: Pierre Saslawsky)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+], URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
Head over to the supplied URL to see the re-paint problem first-hand.

Comment 1

18 years ago

*** This bug has been marked as a duplicate of 42032 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 2

18 years ago
I do not believe that this bug is a duplicate of bug #42032 but rather an effect 
of the other bug. I have found another bug (#42356) that is also an effect.

I have marked this bug as a dependent of #42032. When #42032 gets fixed, I will 
see whether this bug fixes itsels or requires further work.
Status: RESOLVED → UNCONFIRMED
Depends on: 42032
Resolution: DUPLICATE → ---
(Reporter)

Comment 3

18 years ago
Can someone please confirm this bug so that I can keep track of it on my radar.

Comment 4

18 years ago
setting but to New
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

18 years ago
Pierre, please triage these from Clayton's list.
Assignee: clayton → pierre
(Reporter)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 6

18 years ago
I'm going to attach a patch. Marc, Kevin: could you review it?
Keywords: nsbeta2
OS: Windows 98 → All
Hardware: PC → All
Whiteboard: [fix in hand]
Target Milestone: --- → M17
(Assignee)

Comment 7

18 years ago
Created attachment 10277 [details] [diff] [review]
proposed fix
(Assignee)

Comment 8

18 years ago
*** Bug 42032 has been marked as a duplicate of this bug. ***

Comment 9

18 years ago
Pierre, your patch looks fine... Why were we ever calculating a width / height 
that way before? Width is width regardless of where the origin is, no? I did not 
apply and run the patch, so I am assuming that it fixes the problem.
(Reporter)

Comment 10

18 years ago
Thanks for the help guys :-)
(Assignee)

Comment 11

18 years ago
Marc, There is a long history behind that code which you can't suspect 
considering how small the patch is: changes in CSS2 specs interpretations, 
attempts to simpler strategies, regressions and finally reinstatement of outdated 
code. It's finally right now.

Comment 12

18 years ago
Putting on [nsbeta2+] radar.  Patch appears low risk. Approved to checkin for 
patch as shown.
Whiteboard: [fix in hand] → [nsbeta2+]
(Assignee)

Comment 13

18 years ago
Fix checked in nsContainerFrame.cpp and nsPresShell.cpp

Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 14

18 years ago
Shashi,

Not sure were to check repainting problem specifically. Could you please check in 
the latest build and let me know ?
(Assignee)

Comment 15

18 years ago
Chris: the problem was fairly obvious to see when visiting the page at the URL 
above. On page load, the text is progressively unveiled by using the clip 
property, as if you were opening a curtain from the middle of the page towards 
the left and the right edges of the window. In previous builds, only the left 
side of the curtain was opening.
(Reporter)

Comment 16

18 years ago
These comments are based on the 06-27-09 build (Linux & Win98)...

A better page to illustrate this bug can be found at
http://www.narain.com/gecko/dhtml/transitions.html This page demonstrates all
ten of the pseudo-transitions that can be done using clip. As you can see this
demo works perfectly again thanks to Pierre's patch.

There is another problem I am seeing but not 100% sure if it is related to this
bug. I'll describe the problem and let you guys be the jury. First you will need
to head over to http://www.narain.com/gecko/ Once the page finshes loading, you
will see six icons fly across your screen. Next the "Gecko's Realm" banner is
unveiled. As you can see the banner opens up pretty much as designed. Next you
will see a table unveiled using the same technique as the banner, but as you
will witness Mozilla struggles to perform this bit of DHTML. Mozilla brings my
PIII-450 box to it's knees so I can only imagine what it would look like on a
slower system.

What I find bizarre is that Mozilla has no problems with the Transitions demo
(an image) and the banner (plain text) but runs into trouble with the table.
(Assignee)

Comment 17

18 years ago
Shashi: please open a separate bug report for the performance problem and assign 

to HTML Tables.

Comment 18

18 years ago
Thanks, Pierre. Marking verified fixed in the June 30th builds.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.