Closed
Bug 311146
Opened 19 years ago
Closed 19 years ago
position:fixed elements scroll with page / redraw badly
Categories
(Core :: Layout: Positioned, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: tom.pike, Assigned: roc)
References
()
Details
(Keywords: fixed1.8, platform-parity, regression)
Attachments
(4 files)
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•19 years ago
|
||
Comment 2•19 years ago
|
||
that's odd. it's broken on http://www.xiven.com/ but not on other sites.
(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•19 years ago
|
||
(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 7•19 years ago
|
||
bz: Trunk regression.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8.1?
Version: Trunk → 1.8 Branch
Comment 8•19 years ago
|
||
(er, i mean branch regression. my bad.) roc: views-related?
Comment 9•19 years ago
|
||
> Regressed between 20051003 and 20051004
What hours?
Reporter | ||
Comment 10•19 years ago
|
||
(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.
Version: 1.8 Branch → Trunk
Comment 11•19 years ago
|
||
I'll bet this is a regression from bug 281709, esp. since this is windows-only... roc, any idea what's up here?
Comment 12•19 years ago
|
||
works in 20051003 2217pdt build fails in 20051004 0252pdt build http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?treeid=default&module=AviarySuiteBranchTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=20051003+2141&maxdate=20051004+0230&cvsroot=%2Fcvsroot
Comment 13•19 years ago
|
||
ok, I picked up the works in 20051003 2352pdt build at work and that one fails too leaving this list http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?treeid=default&module=AviarySuiteBranchTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=20051003+214100&maxdate=20051003+231300&cvsroot=%2Fcvsroot
Assignee | ||
Comment 14•19 years ago
|
||
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.
Flags: blocking1.8rc1?
Flags: blocking1.8rc1+
Flags: blocking1.8.1?
Assignee | ||
Comment 16•19 years ago
|
||
I still don't have a Windows environment.
Comment 17•19 years ago
|
||
David, can you help out here?
(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•19 years ago
|
||
(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.
I think this is roughly what roc suggested, but it did not fix the bug for me.
Assignee | ||
Comment 21•19 years ago
|
||
I suggest you use Spy++ to check the widget state for the content before and after the patch in bug 281709.
Updated•19 years ago
|
Keywords: regression
Comment 22•19 years ago
|
||
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•19 years ago
|
||
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.
Assignee | ||
Comment 24•19 years ago
|
||
This is bad, but it's not extremely bad. XHTML plus position:fixed is a pretty small set of pages.
Comment 25•19 years ago
|
||
OK, give that this only affects a small set of pages, removing from the blocking radar.
Flags: blocking1.8rc1+ → blocking1.8rc1-
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•19 years ago
|
||
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.
Flags: blocking1.8rc1- → blocking1.8rc1+
Comment 28•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•