43191 - frameset targets not selecting from cached frame

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect, P3)

Description

[Walter Vaughan]

Targeted anchors seem to be causing a refresh of frame.
From this example frameset, select the default search (Lookup Rubber Parts).
You then should be able to get to the shopping cart anchors by hitting the
shopping cart icon, instead it performs a new search inside the frame, losing
the parameters of the original search.

The behavior of this website works as expected on NS 3 -> 4.73 (current)
and Internet Exploder.

Comment 1

[Eric Pollmann]

See nsDocShell::ScrollIfAnchor

Comment 2

[Eric Hodel]

reporter: can we get a more detailed description of how to reproduce this bug
and if it is still present on current nightly builds?  Thanks

Comment 3

[Walter Vaughan]

Just downloaded last night's build [2000072520].
Same problem.
http://166.82.96.9/xframes.html
Click on "Lookup Rubber Parts"
When page builds, click on "Shopping Cart" icon at top.
The targeted frameset should just move the focus to the indicated
anchor and not reload frameset from the server.
Voice at 800-544-8665 x270 8-12,1-5 EST.
or IM'ed at WDVAUGHAN

Comment 4

[Asa Dotzler [:asa]]

confirmed with 072808 m18 m,ozilla bits on NT

Comment 5

[Eric Pollmann]

CC'ing gagan - is this a known issue with the cache?  (Same url with a
#namedanchor added to the end won't hit in the cache.)  

This is a form submit-related bug that prevents the site from being usable at
some core level, but the same function can be achieved by scrolling down to the
bottom of the page.  Thus, I'm not marking this nsbeta3, but Future.

Comment 6

[Eric Pollmann]

netwerk/protocol/http/src/nsHTTPChannel.cpp::CheckCache()  ?

This routine passes in the URI as a key to the cache.  It says something about
needing to add the post data as part of the key in this routine.  Could we also
add something about removing any #namedanchors from the URI before sending off
the key?

Would this change need to be made in other places too?  As a general hunch, I'm
marking this Networking:Cache, but I could be wrong.  I won't reassign until I
can verify that this is actually the problem...

Comment 7

[Eric Pollmann]

Should resolve this by 1.0

Comment 8

[gordon]

Darin, here's a bug that mentions using the anchor tag in HTTP's cache key.  It
was with the old cache, but I think it still applies to HTTP's use of the new
cache as well.  You might want to take this, or at least talk to Eric about it.

Changing component, but I'll let Darin and Eric decide who it should be assigned
to.

Comment 9

[Eric Pollmann]

:) Never got around to verifying - but I strongly suspect this is a cache
change.  Handing to the guru.  :)

Comment 10

[Darin Fisher]

right, the problem is that we don't trim the '#ref' from the URL before using
the URL as a key into the cache.  this means that changing the #ref prevents
causes the cached copy to be skipped *always*.  i think this is critical for
mozilla 0.9.

Comment 11

[Darin Fisher]

Attachment: removes any #ref from the URL before using it as a cache key

Comment 12

[Darin Fisher]

Attachment: simpler PL_strchr based solution

Comment 13

[Gagan]

r=gagan

Comment 14

[Chris Waterson]

Not that it really matters *that* much, but, you should pull mRequest->Spec()
into a temporary instead of invoking the method over and over. (Most compilers
won't optimize away the function call.)

Take it or leave it. sr=waterson

Comment 15

[Darin Fisher]

waterson: turns out nsHTTPRequest::Spec() is an inline method, so the code in
question just amounts to mRequest->mSpec.get()

Comment 16

[Darin Fisher]

fix checked in

Comment 17

[Walter Vaughan]

Same problem.
http://166.82.96.9/xframes.html
Click on "Lookup Rubber Parts"
When page builds, click on "Shopping Cart" icon at top.
The targeted frameset should just move the focus to the indicated
anchor and not reload frameset from the server.

Comment 18

[Darin Fisher]

i don't see it reloading the frameset... instead i see it reloading the 
shopping cart frame only... this happens because for that frame, there
is no expiration information given by the server.  so, it seems to work
for me... linux build 2001-04-18.

Comment 19

[Darin Fisher]

reassigning to browser-general:  i don't know who should get this now.  the
cache/networking should not even be involved.  the problem is with a page
that results from a form POST.  there are links on the page pointing back to
the page with additional #ref's.  these should just cause layout to scroll...
there should not be a network request.

Comment 20

[Walter Vaughan]

Well, magically the problem has gone away at least with build 2001060703 on
Win32 and Linux. Someone fixed something in the last month since I downloaded a
nightly build that solved this issue. The question is will it stay fixed since
this bug was not updated by anyone since it was tossed back on the pile to be
worked on?

Comment 21

[Darin Fisher]

WORKSFORME linux 6/7/2001