Closed Bug 217120 Opened 21 years ago Closed 20 years ago

back button does not restore scroll position when no reflow occurs after history restoration

Categories

(Core :: DOM: Navigation, defect, P2)

x86
All
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: brianlcole, Assigned: roc)

References

(Blocks 1 open bug, )

Details

(Keywords: fixed-aviary1.0, fixed1.7, Whiteboard: [have patch])

Attachments

(3 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1

when clicking the back button, if the link you clicked was in the middle of the
page, the browser would normally scroll down to that link.  i find that it does
not work on many websites such as ebay.com for 1 example. others it does work on.

you may think this is just an ebay thing however it is not, i have experienced
this on many other pages. even if ebay pages were poorly coded, this feature
should still work.

Reproducible: Always

Steps to Reproduce:
1. goto ebay.com and search for something, or display a page in which you need
to scroll down.
2. click a link that you would need to get to by scrolling.
3. press the back button and you will be brough back to the begining of the
previous page instead of where the link you clicked was.

Actual Results:  
you are brough to the top of the previous page.

Expected Results:  
should be brought to the part of the page where the link you clicked was.

forum thread: (not mine)
http://forums.mozillazine.org/viewtopic.php?t=20203&highlight=back+link
Summary: back button or variants dont go back to the stop where the link was clicked on various pages → back button or variants dont go back to where the link was clicked on various pages
Restricting this bug to the problem on search.ebay.com because similar problems
at other sites might be separate bugs (e.g. bug 47350).

I can confirm the bug at search.ebay.com in Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.5b) Gecko/20030823 Mozilla Firebird/0.6.1+.  But it also
happens in Seamonkey, so sending to Session History.
Assignee: blake → radha
Status: UNCONFIRMED → NEW
Component: General → History: Session
Ever confirmed: true
Product: Firebird → Browser
QA Contact: asa → petersen
Summary: back button or variants dont go back to where the link was clicked on various pages → back button does not restore scroll position on ebay
Version: unspecified → Trunk
-> John Keiser (layout history)
Assignee: radha → john
Question for those more familiar with the inner workings:
Someone in the cited Mozillazine forum above suggested the eBay behavior was
related to the meta-tag pragma:no-cache.
Is this bug a manifestation of (and therefore a duplicate of) bug 215405?
This bug is not present in Mozilla 1.4.1 for Linux, compiled
from source.

Martin
Use 98SE and the problem also occurs with this OS.
The scroll issue changes - when I downloaded 1.4.1 this scrolling issue was not
a problem.  Something occurred later which caused the problem.
*** Bug 226153 has been marked as a duplicate of this bug. ***
*** Bug 227427 has been marked as a duplicate of this bug. ***
I am experiencing the exact same bug on WinXP Pro. Firebird 0.7

While viewing a page such as this bug list, or Ebay, I will click on link then
click the back button and the page scroll reverts back to the top of the page
again! This is VERY annoying when dealing with long lists of links and I may
discontinue using this browser if not resolved.

My friend who uses the same OS and browser does not have the same problem...
*** Bug 205391 has been marked as a duplicate of this bug. ***
*** Bug 210992 has been marked as a duplicate of this bug. ***
*** Bug 222719 has been marked as a duplicate of this bug. ***
*** Bug 231423 has been marked as a duplicate of this bug. ***
*** Bug 231981 has been marked as a duplicate of this bug. ***
Steve, what exactly makes you think all those bugs are duplicates of this one?  
Bug 210992 is definitely not the same as all those other bugs, if nothing else.

Please un-dup those bugs unless you have some sort of proof that they are
duplicates of this one (feel free to mark them dependent, though).  Bugs with
similar symptoms but different causes are NOT THE SAME BUG.
Oops! Sorry, in my initial reading of these bugs it looked like they were
duplicates. I'm unduping the bugs except bug 222719 which mentions eBay as its
only example.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040215
Firebird/0.8.0+

This bug is about 80% reproducible on a simple eBay search for "foo".

Saving the page (HTML only) and loading it from disk or localhost brings it down
to 0%.

Adding this to my hosts file brings it down to about 10%:
127.0.0.1 include.ebaystatic.com
127.0.0.1 include.ebay.com
127.0.0.1 half.ebay.com
127.0.0.1 ebay.doubleclick.net

I'm still baffled.
Well, with firefox 0.8 and linux, this is still a nightmare.. My girlfriend
hates linux because of two specific things. #1, this bug exists with any decent
browser under linux. #2, printing is confusing.. 
> 127.0.0.1 include.ebaystatic.com
> 127.0.0.1 include.ebay.com
> 127.0.0.1 half.ebay.com
> 127.0.0.1 ebay.doubleclick.net

Wow.. I tried this before my last post, and it didn't work.. But later I
realised that I still had proxy turned on.. When I tried it later with proxy
turned off, this work around worked wonderfully for me.  With symptoms so
specific, I would think that it might not be too hard to finally find this bug..
(by not too hard, I mean for someone smarter than I)... 

Maybe something with the option to not load images from other sites stomping
something, weather it's set or not.. 
 
Well, if someone writes a minimalish testcase that shows the problem, that would
be a good start.
A workaround I've found is to scroll down a page worth (by pressing the
spacebar) before the page finishes loading (just as the scroll bar has area to
scroll) and normal behavior follows (the browser returns to the previous scroll
position).
*** Bug 238195 has been marked as a duplicate of this bug. ***
Attached patch A quick patch to fix the problem (obsolete) — Splinter Review
This patch rescrolls the view after loading the document. Seems to work for the
ebay positioning problem, but does not address bug 215405 and bug 47350.
Interesting... why does that help, exactly?  That's really weird...
I use 98SE and have not had this problem since 1.4.1 - ebay made changes last
week and the problem has resurfaced.
I upgraded to 1.6 (still using 98SE) and the eBay problem remains (this a very
recent reoccurance of this problem with eBay making some changes to their site.
 Can someone do a quick fix (looks like there is a patch) and put the browser up
for download?  Not everyone has the skill to install the patch and recompile. 
This is a really big thing and may force many to go to IE - I will problably at
least use it for eBay stuff. 
I've been debugging into this and have figured out what the problem is. When
the back button is clicked, the nsScrollBoxFrame::RestoreState() function is
called to set the position of the scrollbar. The actual repositioning of the
scrollbar (the view) is supposed to be done in nsScrollBoxFrame::DoLayout()
which is called while processing the reflow event for the frame. Now, it turns
out that there are no reflow events for the frame after the Ebay page is loaded
(after nsDocument::EndLoad). In this patch, I'm generating a reflow event from
within nsScrollBoxFrame::RestoreState() so that nsScrollBoxFrame::DoLayout()
gets called--and the scrollbar repositioned as per the new co-ordinates.
Attachment #146153 - Attachment is obsolete: true
Bug 47350 also has the same problem. i.e. RestoreState() is called but
DoLayout() isn't.
I guess there is a patch but how does a non-programmer deal with the problem? 
Can  something be done for the masses? 
I've noticed this bug also happens in ebay.  When you view an item, then click
back to click on other items, the vertical scrollbar doesn't remember its'
position.  Rather, the vertical scrollbar returns to the top.

This also happens at www.bestbuy.com when viewing items and then clicking on back. 

please fix this.
Flags: blocking1.8a?
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a)
Gecko/20030728 Mozilla Firebird/0.6.1
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a)
Gecko/20030728 Mozilla Firebird/0.6.1
> 
> when clicking the back button, if the link you clicked was in the middle of the
> page, the browser would normally scroll down to that link.  i find that it does
> not work on many websites such as ebay.com for 1 example. others it does work on.

Hmm... I'm getting this behavior while reading Slashdot. For example:
http://slashdot.org/articles/04/05/03/1814248.shtml?tid=109&tid=187

Scrolling through somewhere below the first screenful, and navigating into the
message hierarchy, when I get back to the top-level for the story or back to the
main slashdot page, the window scrolls back to the top, but returns to the right
scroll position for the other levels of the tree I'm navigating up/down through.

System: Win2KPro SP3, NVidia 5200, through AT&T Worldnet dialup access, Moz
1.7RC1.  mozilla-win32-1.7b worked fine for me. I just upgraded it today to RC1. 
 
> you may think this is just an ebay thing however it is not, i have experienced
> this on many other pages. even if ebay pages were poorly coded, this feature
> should still work.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. goto ebay.com and search for something, or display a page in which you need
> to scroll down.
> 2. click a link that you would need to get to by scrolling.
> 3. press the back button and you will be brough back to the begining of the
> previous page instead of where the link you clicked was.
> 
> Actual Results:  
> you are brough to the top of the previous page.
> 
> Expected Results:  
> should be brought to the part of the page where the link you clicked was.
> 
> forum thread: (not mine)
> http://forums.mozillazine.org/viewtopic.php?t=20203&highlight=back+link

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a)
Gecko/20030728 Mozilla Firebird/0.6.1
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a)
Gecko/20030728 Mozilla Firebird/0.6.1
> 
> when clicking the back button, if the link you clicked was in the middle of the
> page, the browser would normally scroll down to that link.  i find that it does
> not work on many websites such as ebay.com for 1 example. others it does work on.
> 
> you may think this is just an ebay thing however it is not, i have experienced
> this on many other pages. even if ebay pages were poorly coded, this feature
> should still work.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. goto ebay.com and search for something, or display a page in which you need
> to scroll down.
> 2. click a link that you would need to get to by scrolling.
> 3. press the back button and you will be brough back to the begining of the
> previous page instead of where the link you clicked was.
> 
> Actual Results:  
> you are brough to the top of the previous page.
> 
> Expected Results:  
> should be brought to the part of the page where the link you clicked was.
> 
> forum thread: (not mine)
> http://forums.mozillazine.org/viewtopic.php?t=20203&highlight=back+link

Funny thing is that using Bugzilla 2.16.3 also exhibits this behavior. We use
this version as our company bug reporting software. I'll move down half a page,
click on a bug number, then use the back button to return, and I am at the top
again.
Scott: that's bug 47350, not this bug.
Flags: blocking1.8a? → blocking1.8a-
I have experienced this with various sites as well. Not all, but a lot. It would
be very nice if this was fixed permenantly. Looking at the history it seems to
be a recurring issue (bugs 46877, 47350 )

using Mozilla 1.6
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

on xp Pro
Ya know, I'm not much of a programmer, but it seems to me like it wouldn't be
hard  to fix this problem... Possibly with an extension.. I know this is not
actually a fix, but why wouldn't this work, and why wouldn't it be better.. It
seems to me that this solution would "fix" this bug, and the other that it's
always confused with, and have the side affect of improving user experience over
all. OK, here's my actual thought:

Why couldn't a plugin be made that keeps the last two or three pages in your
history in a hidden tab, and then if you click the back button, it simply closes
your current tab and shows you the hidden tab. If you go back too far, then
pages need to be re-rendered, and the whole bit, and then you'd be able to see
this bug, but 99% of the time, you'd never see it.. especially on sites like
ebay, where you simply browse into a sinlge item, and back out of it all the time. 

This is basically how I navigate ebay, so that firefox doesn't drive me
absolutely nuts... the only difference is, I can see the tabs, and I change
where I click.. Given the capabilities of a lot of the modules out there, it
seems that all the hooks that are needed, are probably there already (ok, not so
sure about creating invisible tabs, but all the interception of clicks, and
taking different actions seem to be par for the course). You could even make the
number of invisible tabs stored be a user configurable options, and that would
give you a chance to warn the user that pages won't be re-rendered, or reloaded,
and warn them about the enormous amount of ram they'll be wasting. I'd jump at
it in a heartbeat.
Confirming the e-bay bug in the newly released Firefox 0.9, Linux
version.
Please fix it soon.

Martin.
(In reply to comment #35)
> Confirming the e-bay bug in the newly released Firefox 0.9, Linux
> version.

Same here. Should the OS be changed to "All"?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040616 Firefox/0.8.0+
(daihard: P4/SSE-2)
1. Goto www.ebay.com
2. Enter "otari" in the "What are you looking for?" window. Actually, you can
probably enter anything that results in a long list of "found" items.
3. Click on the "Find It" button.
4. You will see a new page with a list of "found" items that is two or three
screens long, requiring scrolling to view the entire list.
5. Click on an item nearer the end of the list to go to the page for that item.
6. After going to the page for that item, click on the "Back" button to return
to the page with the "Found" list.
The problem: Firefox (and previously Firebird for a long time) returns you to
the TOP of the page for the "Found" list. It SHOULD return you to the scrolled
location. Long ago it worked in Firebird. but has not worked in Firebird or
Firefox for many months. Thank you.
OS: Windows XP → All
(In reply to comment #37)
> Long ago it worked in Firebird. but has not worked in Firebird or
> Firefox for many months. Thank you.

Sounds like a regresssion.  What version does it work in, and what version did
it stop working in?
This occures also within very simple pages.

Example (ripped from one of my own page that bugs):

---------------------------------------------------------------

<html>
<head>
<title> Sekalaisia kuvatuksia </title>
</head>

<body>

<br><br><center><h1> TOPIC HERE </h1></center>

<br><blockquote> Couple of lines text in here in blockquote<br> </blockquote>

<p><a href="img01.jpg"><img src="mini_imgs/img01.jpg"></a>
Image: img01.jpg
</p><br clear=all>

<p><a href="img02.jpg"><img src="mini_imgs/img02.jpg"></a>
Image: img02.jpg
</p><br clear=all>

<p><a href="img02.jpg"><img src="mini_imgs/img02.jpg"></a>
Image: img02.jpg
</p><br clear=all>


(and couple of more similar links, up to 8 to 10 depending on image size).


</body>
</html>

---------------------------------------------------------------------

In page example above, the only thing to reproduce bug is to click some image
link that requires scrolling. Then click back button. If it works properly, then
 click again that same image link and back.

Usually it wont take more than 1-4 tries until bug occurs and place in link page
is restored to the top.
After installed the AdBlock extension(V.5 d.2 nightly39), the back button
problem is fixed. It's strength, but true.
(In reply to comment #40)
> After installed the AdBlock extension(V.5 d.2 nightly39), the back button
> problem is fixed. It's strength, but true.

Yes, the Adblock workaround has proven to work here as well. It's one of the
most frequently asked questions in the German Firefox forums, but applying the
two filters doubleclick.net and /\/ads\// seems to solve the "ebay back" problem
for everyone. The latter filter filters a couple of JS scripts. (Click on the
'Adblock' link in the status bar for a list of filtered items)
(In reply to comment #41)

wowow, /\/ads\// is a litte bit BIG, isn't it?

I've found it. It's a js script. You only have to block

http://include.ebaystatic.com/aw/pics/js/lib/features/ads/footer_ads_ns.js

...and then it works... but where is the bug inside...

here it is:

//<!--
//\include\js\lib\features\ads\footer_ads_ns.js@@\main\1

var isNS4x=false;if(document.layers)
isNS4x=true;function processAdLayers()
{if(isNS4x)
{if(typeof(_ebayAds)!="undefined")
{var h="";for(var i=0;i<_ebayAds.length;i++)
{var lId=_ebayAds[i].layerId;var lW=_ebayAds[i].config.ifWidth;var
lH=_ebayAds[i].config.ifHeight;h+='<LAYER SRC="'+_ebayAds[i].adUrl+'"
width="'+lW+'" height="'+lH+'" visibility="hidden"
';h+='onLoad="moveToAbsolute('+lId+'.pageX,'+lId+'.pageY);clip.height='+lH+';clip.width='+lW+';';h+='
visibility=\'show\';"></LAYER>';}
document.write(h);}}}
function eOnResize()
{if(innerWidth!=origWidth||innerHeight!=origHeight)location.reload();}
if(isNS4x)
{processAdLayers();origWidth=innerWidth;origHeight=innerHeight;onresize=eOnResize();}
// -->

(In reply to comment #42)

But apparently the same js ad code code not keep IE from restoring the search
results scroll position when we back-arrow to the search results list after
viewing an item in the list?

So is Firefox somehow causing a condition that makes that js code put us back at
the top of the Ebay search results page when we back-arrow to the page?

I am vote #40 for this bug - I just recently got scared enough of IE to switch
to Firefox, but I use Ebay a lot and this bug makes Firefox really annoying to
use for Ebay.

Carolyn
This bug needs to be updated so it's not ebay specific. I can reproduce this
behaviour on any site with FireFox 0.9.1. For example:

1. Go to mozillazine forums home: http://forums.mozillazine.org/index.php
2. Scroll down a bit and click on the link to the Mozilla General Forum
3. Click back
4. Repeat 2 and 3

After doing this n times you will end up back at the top of the page. On some
sites this happens more frequently and on others less.

I think the severity of this bug needs to be upgraded as well. If you look at
the Firefox Bugs MozillaZine Forum you will see that there are numerous reports
of this behaviour.

Luke.
Taking. Comment #26 sounds reasonable, I'll take a deeper look to see if it's
the right fix.
Assignee: john → roc
Priority: -- → P2
Firefox and/or Windows only? I can't reproduce in Mozilla on Linux. That'll make
it hard for me to fix...
Attached patch fix (obsolete) — Splinter Review
Manish was right on the money. This is basically his patch, but I've moved the
check out to nsPresShell::EndLoad because it's the only place where state
restoration isn't guaranteed to be followed by a reflow (the other call sites
are in nsCSSFrameConstructor right after the frame is created).

What I think happens here is that we load most of the document and reflow it,
then the EndLoad notification comes, but it turns out that there was no new
content that required reflowing, so we don't reflow again. Basically what
Manish said.
Attachment #146389 - Attachment is obsolete: true
Comment on attachment 152645 [details] [diff] [review]
fix

We need to ensure that after restoring the state, a reflow is definitely issued
against the scrollframe. Most of the time this is true because we've just
created the scrollframe, but not here.

I haven't been able to test this myself, but I presume it works because Manish
said his patch (nearly identical to this) worked.
Attachment #152645 - Flags: superreview?(dbaron)
Attachment #152645 - Flags: review?(dbaron)
Comment on attachment 152645 [details] [diff] [review]
fix

Is there a way we can do this without a reflow command?  Or is this more
efficient than I think it is?

(Also, I hope this code goes away soon.  But it would probably be moved
somewhere else, so we do want it to be right.  See bug 103279.)
We could factor out the scroll-position restoration code into a separate method
in nsScrollBoxFrame, make it accessible via nsIScrollableFrame, and then call it
directly instead of doing the reflow. That's definitely a good idea.
Depends on: 251784
i created meta bug 251784 to track issues like this one.

i don't understand the exact nature of this particular bug.  could manish,
robert, or somebody else who does understand come up with a better summary?  i'm
assuming that this bug can be triggered by sites other than ebay.
Attachment #152645 - Flags: superreview?(dbaron)
Attachment #152645 - Flags: superreview-
Attachment #152645 - Flags: review?(dbaron)
Attachment #152645 - Flags: review-
Flags: blocking-aviary1.0RC1?
*** Bug 252009 has been marked as a duplicate of this bug. ***
Blocks: 251784
No longer depends on: 251784
roc, think a fix for this will make RC1 in a couple of weeks?
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1+
Attached patch better fixSplinter Review
I think this is what David had in mind ... I've split out the "scroll to
history position" code into its own function in nsScrollBoxFrame, which is
still called during reflow, but can also be called from nsPresShell via
nsIScrollableFrame.
Attachment #152645 - Attachment is obsolete: true
Comment on attachment 154060 [details] [diff] [review]
better fix

I tested this and history scrolling still works ... but I can't seem to
reproduce the original bug so I'm not sure this fix works. But I assume it does
based on the other comments in this bug.
Attachment #154060 - Flags: superreview?(dbaron)
Attachment #154060 - Flags: review?(dbaron)
dbaron, can you review?  I'm thinking we should get this in quickly and start
baking it on trunk and branches..
Attachment #154060 - Flags: superreview?(dbaron)
Attachment #154060 - Flags: superreview+
Attachment #154060 - Flags: review?(dbaron)
Attachment #154060 - Flags: review+
checked in. Leaving open for possible 1.7 and Aviary checkin.

Can the people on this bug please try to download a Firefox nightly trunk build
tomorrow and let me know if it fixes this bug for them?
(In reply to comment #58)
> checked in. Leaving open for possible 1.7 and Aviary checkin.
> 
> Can the people on this bug please try to download a Firefox nightly trunk build
> tomorrow and let me know if it fixes this bug for them?

Yes, I'll do that. Using w2k. Thanks for accelerating work on it.
(In reply to comment #58)
> checked in. Leaving open for possible 1.7 and Aviary checkin.
> 
> Can the people on this bug please try to download a Firefox nightly trunk build
> tomorrow and let me know if it fixes this bug for them?

I'll give it a shot too.. I'm running a few linux machines, and have a windows
machine available at work as well.. all of which have the problem, so I'll try
it everywhere.
(In reply to comment #58)
> checked in. Leaving open for possible 1.7 and Aviary checkin.
> 
> Can the people on this bug please try to download a Firefox nightly trunk build
> tomorrow and let me know if it fixes this bug for them?

The 19:04 build from last night, on the FTP site this morning, still has the
same behavior, i.e.,  returning to the top of a scrolled page rather than to the
departure point. Using w2k.
What's your build ID?

Manish, if you're around I think I need your help...
(In reply to comment #62)
> What's your build ID?
> 
> Manish, if you're around I think I need your help...

This is what the 'help' screen shows:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040723
Firefox/0.9.1+
Same problem with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040724

To repeat my test: Go to www.ebay.com and enter something in the Search window
that generates a page with a long list of items that requires scrolling to get
to the bottom of the list. Scroll to a point near the bottom of the list, click
on an item to go to a page about that item. Click the Back button and you SHOULD
be returned to the point on the previous page near the bottom of the list. But,
you are returned to the TOP of the page instead. Thanks for trying.

John Hardy
Can still reproduce on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8a3) Gecko/20040724 Firefox/0.9.1+
I tried the later build of FF added this morning; it still does not work with w2k. 

Build data is:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040724
Firefox/0.9.1+

Like many eBayers, I'll output 100-item pages to visually screen as many items
as possible in a short period of time. Here is a tinyurl pointing to a typical
eBay query that demonstrates the problem:

http://tinyurl.com/69lhr
I'm back. ;)

I am still able to reproduce the bug with the latest build (Jul-24) of Mozilla
(and I can see that the fix is in there). In the PresShell::EndLoad(...)
function, scrollableFrame is null, because of which ScrollToRestoredPosition()
is not getting called at all.

Steps to reproduce:

1. Go to http://www.ebay.com/
2. Search for "pineapple" (or anything else).
3. Scroll down a little bit and click on one of the products.
4. Use the Back button to return to the previous page.

Result: The scroll position is not restored.

Rob, we need to see why scrollableFrame is null.
Attached patch improved fix...Splinter Review
Alright, that didn't work because GetRootScrollFrame actually returns the
*scrollbox* for the root scroll frame, rather than the nsIScrollableFrame
itself. So, we need to call ScrollToRestoredPosition on the root scroll frame
itself but continue to call Capture/RestoreState on the scroll box. This patch
does that.

Pretty soon I plan to move the history state to the actual scroll frame at
which time the scrollbox-getting code here can be removed. It's just wrong for
the presshell to know about how the scrollframe organizes its children, anyway.
Okay Manish, can you test this?
Yes! It's working!
Comment on attachment 154316 [details] [diff] [review]
improved fix...

Alright David, this patch actually works :-)
Attachment #154316 - Flags: superreview?(dbaron)
Attachment #154316 - Flags: review?(dbaron)
NOT working:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040725
Firefox/0.9.1+

Is the fix being tested on the trunk or branch or both? Thank you.
It hasn't been checked in yet. To test this, you need to make your own build
with the patch applied.
Attachment #154316 - Flags: superreview?(dbaron)
Attachment #154316 - Flags: superreview+
Attachment #154316 - Flags: review?(dbaron)
Attachment #154316 - Flags: review+
Okay, I just checked this in. So it should be showing up in nightly builds soon.
It seems to work now, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040728
Firefox/0.9.1+
Thank you very much!
I think bug 238195 is also fixed by this (at least it does for me).
Comment on attachment 154060 [details] [diff] [review]
better fix

requesting approvals
Attachment #154060 - Flags: approval1.7.2?
Attachment #154060 - Flags: approval-aviary?
Comment on attachment 154316 [details] [diff] [review]
improved fix...

requesting approvals ... this is part #2 of the same bug
Attachment #154316 - Flags: approval1.7.2?
Attachment #154316 - Flags: approval-aviary?
(In reply to comment #74)
> Okay, I just checked this in. So it should be showing up in nightly builds soon.

Thanks very much for working your way through this one. I have drilled several
layers deep and have returned with no manifestations of the prior behavior.
Thanks, again.
Comment on attachment 154060 [details] [diff] [review]
better fix

a=ben@mozilla.org for aviary br
Attachment #154060 - Flags: approval-aviary? → approval-aviary+
Comment on attachment 154316 [details] [diff] [review]
improved fix...

a=ben@mozilla.org for aviary br
Attachment #154316 - Flags: approval-aviary? → approval-aviary+
roc, can you land on the branch?  thx
Whiteboard: [have patch]
robert: want to update the summary as requested in comment #51?  probably want
to change OS -> All, Platform -> All, too, while you're at it :)
Landed on 1.7.3 branch. I'll attach the patch that I used, which should be easy
to apply to Aviary.
Forgive my ignorance but what does this mean in terms of this fix hitting a
nightly Firefox official branch build any time soon?  
*** Bug 254528 has been marked as a duplicate of this bug. ***
(In reply to comment #83)
> Landed on 1.7.3 branch. I'll attach the patch that I used, which should be easy
> to apply to Aviary.

Please, can you checkin the fix for the branch, Please.
Thanks
This not only happens with ebay, but many messageboards completely randomly.
About 75% of the time it will return me to the previous location, the other 25%
of the time it will put me at the top of the page... example of this...

http://www.investorshub.com/boards/board.asp?board_id=1125

click on a few threads in the middle and press the back button.
(In reply to comment #88)
> This not only happens with ebay, but many messageboards completely randomly.
> About 75% of the time it will return me to the previous location, the other 25%
> of the time it will put me at the top of the page... example of this...
> 
> http://www.investorshub.com/boards/board.asp?board_id=1125
> 
> click on a few threads in the middle and press the back button.

I'm using the patched code as it has been introduced into the nightlies. I just
tried it on 30 different investorshub threads without the previous 'difficulty'
emerging. I'm using w2k.

Maybe you'll get relief by trying a recent nightly.
(In reply to comment #89)
Thats the point, it is not yet in any official nightly branch build.  I just
tried the Firefox 8/8 build and it still fails.  Hence my comment #85 sking when
it might appear.
Ben Goodger promised to check it into the Aviary branch soon. Don't worry, it
will make 1.0.
I landed this patch on the aviary branch just now. 
Keywords: fixed-aviary1.0
Marking fixed now that it's been checked in everywhere.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
imnsho, we still have a crappy summary for this bug.  robert?

(this is basically a repeat of comment #82 that has been ignored like comment #51)
better? :-)
Summary: back button does not restore scroll position on ebay → back button does not restore scroll position when no reflow occurs after history restoration
Fixed and working fine in 8/10 Branch build.
Thanks to all.. 
not working for me
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040811
Firefox/0.9.1+
(In reply to comment #97)
> not working for me
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040811
> Firefox/0.9.1+

Agreed.. It's not working for me either

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040811
Firefox/0.9.1+ 
(In addition to comment #98)

More info...

Using http://www.squarefree.com/burningedge/ as an example page, the fix is
working. But, it doesn't seem to work on the various "vBulletin" hosted forums I
hang out on. For example:

- Goto http://www.yotatech.com/forumdisplay.php?f=2
- Scroll to the bottom of the page
- Click on the last "thread" in the list
- hit BACK
- You'll be at the top of the list

I'd be temped to say this was a vBulletin software issue, but "preserve cursor
location on BACK" works with IE.
You may be seeing a different bug.  Try looking in Bug 251784 (the meta scroll
position bug)
Kurt: On which site does it not work for you?

Mark: Scroll position isn't remembered on
http://www.yotatech.com/forumdisplay.php?f=2 because the site uses no-store.
That's bug 215405, not this bug.
Here is a new twist I noticed - delayed scroll to previous position.

NOTE - I do NOT have the "branch" release - I only have 0.9.2.  But I thought
the following information might be useful.

Firefox 0.9.2 (the public release)
Windows NT

After failing to restore Ebay list scroll position, Firefox returns scroll
position AFTER a subsequent action:

After Firefox fails to return to the scroll position when using back button to
get back to the Ebay item list, if I immediately enter a new search term at the
top of the item list page and click the Search button, Firefox scrolls to my old
position on that page instead of searching.  I must scroll up and press Search
again, and then the search is executed.

To reproduce:

1. Go to http://www.ebay.com/

2. Click the Search button at top of page to get to Search page

3. Enter the word: cat

4. Click the Search button

5. You now have a list of cat items.  Use the scroll bar to croll down the
page to an item near the bottom of the list.  Click on the name/description
of that item.  You are taken to that item's page.

6. Press the browser back button to return to the list page.  Instead of
being returned to a scroll position near the item description you clicked in
step #5, you are repositioned to the top of the list page. (the bug
discussed above)

7. (*NEW DISCOVERY*) Now immediately enter a new search term (for example:
dog)in the search box at the top of the list page (your current page).
Press the Search button.  Firefox NOW scolls to your old position in the
list instead of executing the search.

8. Scroll back to the top and press Search AGAIN, and the new search gets
executed.

Carolyn S.
> Mark: Scroll position isn't remembered on
> http://www.yotatech.com/forumdisplay.php?f=2 because the site uses no-store.
> That's bug 215405, not this bug.

Ahh.. okay. Thank you Jesse (and you too Robert!)


fwiw, Carolyn: I don't see the problem that you describe with using the 8.11.04
branch build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040811
Firefox/0.9.1+ 
I have seen the "*NEW DISCOVERY*" problem that Carolyn describes every once in a
while. Not often enough to figure it out or think it through, but I've seen it.
*** Bug 255513 has been marked as a duplicate of this bug. ***
*** Bug 251616 has been marked as a duplicate of this bug. ***
*** Bug 257635 has been marked as a duplicate of this bug. ***
*** Bug 258133 has been marked as a duplicate of this bug. ***
Just upgraded to Mozilla 1.7.2 and the problem is still there with respect to
eBay.  In addition, the "sort by" stopped working.  This product still has
problems and IE is beginning to look very good.
*** Bug 264087 has been marked as a duplicate of this bug. ***
*** Bug 253416 has been marked as a duplicate of this bug. ***
I'm having the same problem with this webpage:
www.themagiccafe.com
Once you enter the "dining room", scroll down to the middle of the page and
click on a link. When you hit the back button, it brings you to the top of the
page. I'm new to Mozilla so can someone guide me to what's happening with this
issue???
(In reply to comment #112)
> I'm having the same problem with this webpage:
> www.themagiccafe.com
> Once you enter the "dining room", scroll down to the middle of the page and
> click on a link. When you hit the back button, it brings you to the top of the
> page. I'm new to Mozilla so can someone guide me to what's happening with this
> issue???

The issue itself is resolved. The solution doesn't exist in any products yet
because there haven't been any milestone releases since this happened.

If you're using Firefox, it should be in the 1.1 release, or the 1.8 release of
the Suite.
(In reply to comment #113)
> The issue itself is resolved. The solution doesn't exist in any products yet
> because there haven't been any milestone releases since this happened.

The previous poster must be referring to a different bug, because I was able to
reproduce the problem he described in Mozilla trunk version 2005013106, which
has the fix for this bug. Note there are several bug dealing with the symptom of
not properly restoring the scroll position.
(In reply to comment #114)

> The previous poster must be referring to a different bug, because I was able to
> reproduce the problem he described in Mozilla trunk version 2005013106, which
> has the fix for this bug. Note there are several bug dealing with the symptom of
> not properly restoring the scroll position.

No, I was referring to THIS bug. See comment 68 thru comment 93. Perhaps the
website is having difficulty with this for another reason. (see comment 100 or 101).
(In reply to comment #115)
> No, I was referring to THIS bug...

Yes, YOU were referring to this bug, but I was referring to the bug Bob Plaut
was referring to.
*** Bug 344680 has been marked as a duplicate of this bug. ***
Component: History: Session → Document Navigation
QA Contact: chrispetersen → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: