Closed Bug 126646 Opened 23 years ago Closed 23 years ago

reload required to load/display any url with fragment (#foo)

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 126981
Milestone:
mozilla0.9.9

People

(Reporter: bugzilla, Assigned: alecf)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: fix in hand, waiting on reviews)

Attachments

(1 file)

the fix
663 bytes, patch
Details | Diff | Splinter Review 
i am filing this as a new bug despite the risk of it being a duplicate of bug
91528, since i have not experienced it before yesterday's (20020219x) builds.
the workaround is identical(reload), the problem is only slightly similar:

steps to reproduce: goto www.mozillazine.org , view comments for top (any)
article (threaded). then attempt to view a reply. ("works" with slashdot
comments as well..)
reproduction frequency: always
expected: new page (reply) is loaded and rendered.
actual behaviour: location bar changes (&message=...#... appended). page does
not load(?)/render unless "reload" is used.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020220
discovered easier reproduction method:
enter url of choice into location bar, append a target anchor (for example
http://www.mozillazine.org/#bogus ).
Summary: reload required to load/display forum → reload required to load/display forum
I see this with 2002022003 on w98 (OS -> All).

It's really frustrating to attempt to read /. or mozillazine now.

Besides hitting reload to get the correct page, you can click on the link again
and then the new page will load.

Note that moving back/forward is affected by this as well as restoring scroll
position.  For example,
1) load slashdot.org (OK)
2) click on a Read More link (OK)
3) click on a child of a comment (location bar changes, page does not)
4) click on the same link again (child comment page loads and scrolls to anchor)
5) click on the back button (location bar changes correctly to the main article,
but the page displayed is the child's page scrolled to the top)
6) click reload (location bar is correct, page is correct, BUT scroll position
is lost)

Note that the Go and Back/Forward history list looks correct all the time.
*** Bug 126706 has been marked as a duplicate of this bug. ***
confirmed ->layout.
Assignee: asa → attinasi
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
Keywords: regression
QA Contact: doronr → petersen
Also seeing this on Win98, build 2002021915. Platform->All.
OS: Linux → All
This is a serious regression that I narrowed down (using Linux builds) to being
between 2002-02-19-06 and 2002-02-19-21, although comment 5 gives an earlier end
bound.  This seems related to some jumping around that occurs the first time
when trying to click a link when viewing a URL with a fragment that isn't
mentioned in this bug, but I strongly suspect it's the same problem.

This *must* be fixed for 0.9.9.
Blocks: 122050
Summary: reload required to load/display forum → reload required to load/display any url with fragment (#foo)
This was caused by alecf's nsDocShell.cpp changes.
Assignee: attinasi → alecf
*** Bug 126872 has been marked as a duplicate of this bug. ***
*sigh* I didn't even realize a reload was happening. damn this fast connection! :) 

this shouldn't be too hard to figure out..I'll try to have a fix today
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: eta 2/21
Target Milestone: --- → mozilla0.9.9
*** Bug 126925 has been marked as a duplicate of this bug. ***
Attached patch the fix — — Splinter Review 
oops.. so I got the logic reversed here, and it was causing two problems - the
one described in this bug, and a bug where if you clicked on a link to another
page that had an anchor, the first click wouldn't actually go through

The logic in ScrollIfAnchor() should have said "If we're on different pages,
then just return"
instead it said "If we're on the same page, then return"

If in fact you clicked on a link to an anchor within the same page then
docshell would think "oh, it's on a different page, so go load that page" and
go load it
If you were clicking to an anchor on another page, docshell would say "oh,
we're on the same page so I'll just scroll to it" - and of course there would
be nothing to scroll to... but docshell would have though the new page was
loaded, so the next time you clicked on the link, the reversed logic would have
caused the page to load again

Anyway, long explanation for a simple fix. looking for reviewers now..
oh, and if you look at the changes I made you can see the old line said
something to the effect of:
if (sCurrentLeft.Compare(...) != 0)

Adding radha for review, darin for sr=
Whiteboard: eta 2/21 → fix in hand, waiting on reviews
dammit, mscott beat me to it!

*** This bug has been marked as a duplicate of 126981 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Well, one of both is wrong. This still isn't fixed, although 126981 is resolved
fixed.

Tested on: Linux 2002022006

Reopen this bug or 126981?
wfm on linux 2002022121
That was stupid :( I seemingly forgot to unpack the new installation files and
used old ones instead.

wfm 2002022121 Linux

Just pulled the tree at about 1800UTC. Now I can do wfm on FreeBSD as well.

(And I've got to find out how to control the build ID as it still says 20020220,
but that's a different story.)

*** Bug 127304 has been marked as a duplicate of this bug. ***
Why was the resolution state of this bug marked as "DUPLICATE" when it was 
clearly a "FIXED"??

because the DUPLICATE that this was marked a dupe of, was fixed. that's how it
works.
This bug should be RE-OPENED.

I'm having the same problem (identical!) with firefox 1.0.2 (ubuntu):
"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050524 Firefox/1.0.4
(Ubuntu package 1.0.2 MFSA2005-44)"
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: