Last Comment Bug 311146 - position:fixed elements scroll with page / redraw badly
: position:fixed elements scroll with page / redraw badly
Status: RESOLVED FIXED
: fixed1.8, pp, regression
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: 1.8 Branch
: x86 Windows XP
: -- normal with 1 vote (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
:
Mentors:
http://www.xiven.com/
Depends on:
Blocks: 281709
  Show dependency treegraph
 
Reported: 2005-10-04 17:41 PDT by Tom Pike
Modified: 2011-08-05 22:37 PDT (History)
19 users (show)
asa: blocking1.8rc1+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
screenshot (84.78 KB, image/png)
2005-10-04 17:49 PDT, Shayne Jewers
no flags Details
Minimized XHTML testcase (412 bytes, application/xhtml+xml)
2005-10-05 01:21 PDT, Tom Pike
no flags Details
Minimized HTML testcase (324 bytes, text/html)
2005-10-05 01:22 PDT, Tom Pike
no flags Details
patch that did NOT fix the bug (1.34 KB, patch)
2005-10-16 00:34 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review

Description Tom Pike 2005-10-04 17:41:06 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051004 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051004 Firefox/1.4.1

Elements on the page that are supposed to be fixed position are being scrolled
with the page and are redrawn incorrectly when scrolled back into view.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.xiven.com/
2. Scroll down
3. Scroll back up again

Actual Results:  
Right menu scrolls with the page when scrolling down and is redrawn incorrectly
when scrolling back up.

Expected Results:  
Right menu should not move when the page is scrolled.

Regressed between 20051003 and 20051004
Comment 1 Shayne Jewers 2005-10-04 17:49:23 PDT
Created attachment 198531 [details]
screenshot
Comment 2 Frank Yan (:fryn) 2005-10-04 17:51:23 PDT
that's odd.

it's broken on http://www.xiven.com/

but not on other sites.
Comment 3 Tom Pike 2005-10-04 17:58:41 PDT
(In reply to comment #2)
Could be that it's only broken for XHTML?

http://www.xiven.com/weblog?force=html (same page but in HTML) seems fine.
Comment 4 Frank Yan (:fryn) 2005-10-04 18:44:49 PDT
(In reply to comment #3)
> (In reply to comment #2)
> Could be that it's only broken for XHTML?
> 
> http://www.xiven.com/weblog?force=html (same page but in HTML) seems fine.

hmm.. interesting.

if someone has time, try making 2 test pages, one with XHTML and a .xhtml
extension, etc. and one with HTML and a .html extension.

That just might narrow it down to what is needed for a fix.
Comment 5 Tom Pike 2005-10-05 01:21:21 PDT
Created attachment 198556 [details]
Minimized XHTML testcase
Comment 6 Tom Pike 2005-10-05 01:22:29 PDT
Created attachment 198557 [details]
Minimized HTML testcase
Comment 7 Hixie (not reading bugmail) 2005-10-07 17:51:12 PDT
bz: Trunk regression.
Comment 8 Hixie (not reading bugmail) 2005-10-07 17:51:55 PDT
(er, i mean branch regression. my bad.)

roc: views-related?
Comment 9 Boris Zbarsky [:bz] 2005-10-07 17:55:26 PDT
> Regressed between 20051003 and 20051004

What hours?
Comment 10 Tom Pike 2005-10-07 18:04:21 PDT
(In reply to comment #9)
> What hours?

Must have been between the nightly builds of 2005-10-03-08 and 2005-10-04-08. 
Sorry I can't be more specific this time.
Comment 11 Boris Zbarsky [:bz] 2005-10-07 18:26:12 PDT
I'll bet this is a regression from bug 281709, esp. since this is windows-only...

roc, any idea what's up here?
Comment 14 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-10-09 12:53:44 PDT
Bug 278353 is similar and it's probably the same issue here: widgets for
fixed-pos elements being created/shown in a different order so that they're no
longer on top of the scrollport widget for the viewport.

Indeed, nsWindow::Show for Win32 does sometimes move the widget to top. You
could try making this unconditional:
http://lxr.mozilla.org/mozilla/source/widget/src/windows/nsWindow.cpp#1671
but that might be risky.
Comment 15 Asa Dotzler [:asa] 2005-10-11 17:12:06 PDT
ROC, we need your help on this. Time
Comment 16 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-10-11 17:50:24 PDT
I still don't have a Windows environment.
Comment 17 Asa Dotzler [:asa] 2005-10-14 13:04:40 PDT
David, can you help out here? 
Comment 18 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-10-15 13:43:16 PDT
(In reply to comment #11)
> I'll bet this is a regression from bug 281709, esp. since this is windows-only...

I confirmed this by local backout.


Also, it seems to me that attachment 198556 [details] shows the bug but attachment 198557 [details]
does not.  Is that what others were seeing?
Comment 19 Blake Kaplan (:mrbkap) (please use needinfo!) 2005-10-15 13:45:17 PDT
(In reply to comment #18)
> Also, it seems to me that attachment 198556 [details] [edit] shows the bug but
attachment 198557 [details] [edit]
> does not.  Is that what others were seeing?

Yes, see comment 2 and comment 3.
Comment 20 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-10-16 00:34:52 PDT
Created attachment 199717 [details] [diff] [review]
patch that did NOT fix the bug

I think this is roughly what roc suggested, but it did not fix the bug for me.
Comment 21 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-10-16 11:53:20 PDT
I suggest you use Spy++ to check the widget state for the content before and
after the patch in bug 281709.
Comment 22 djpohly 2005-10-16 15:55:34 PDT
Not sure if this might help...

On the testcase, the bug does not occur if you use autoscroll.  What's more, as
soon as you click and the marker appears, the div fixes itself.
Comment 23 Asa Dotzler [:asa] 2005-10-18 14:59:59 PDT
David, and Robert, time is running out here. If we don't have something (and
something pretty safe) in the next couple of days, this is gonna miss the 1.8
releases.
Comment 24 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-10-18 15:27:55 PDT
This is bad, but it's not extremely bad. XHTML plus position:fixed is a pretty
small set of pages.
Comment 25 Asa Dotzler [:asa] 2005-10-19 07:09:54 PDT
OK, give that this only affects a small set of pages, removing from the blocking
radar.
Comment 26 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-10-19 09:46:31 PDT
We need to block on this.

Yes, it's a subset of 'position:fixed' pages.

But 'position:fixed' is one of the top features that Web developers like
about Gecko that IE doesn't implement.  So much so that IE7 is
implementing it.  If we break it in the 1.5 release (which likely means
it will also be broken for the 2.0 release), it will do significant
damage to our reputation with Web developers.

I think the fact that we even considered taking such low-level changes
as bug 281709 to fix a cosmetic bug as late in the game as we took them
says our process is broken.  The bug that caused this regression should be
backed out.
Comment 27 Asa Dotzler [:asa] 2005-10-19 11:13:41 PDT
David or Robert, we need to try to get a fix for this. Backing out 281709 would
be a major UI regression over 1.0 and if we consider that, then I think we also
need to consider backing out the change that broke our menus in the first place.
Comment 28 Boris Zbarsky [:bz] 2005-10-19 13:43:48 PDT
Backing out the change that broke the menus in the first place would reintroduce
a DHTML bug that was one of the major complaint of web authors about our DHTML
impl....  (see the bugs bug 244366 blocks).

I'll put some comments in bug 281709 that might lead us to a solution, but I
need a Windows buddy to have a hope of getting anywhere on this... :(
Comment 29 Scott MacGregor 2005-10-20 16:36:42 PDT
The patch which introduced this regerssion has been backed out of the branch and
we have another fix which should fix the drop shadow issue without causing this
regression.

I'm going to mark this fixed but we should still get a verification on the
branch tomorrow.
Comment 30 Peter van der Woude [:Peter6] 2005-10-20 18:17:57 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051020
Firefox/1.5 ID:2005102017

Verified fixed on branch

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