207880 - No session history (= back/forward buttons) is created for a frame which is "replaced" during frameset initial load

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Serge Gautherie (:sgautherie)]

User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030529

This bug is based on bug 201108 (see that bug for testcase files and real URL),
like it, this bug applies both to the testcase and the actual (private) site.

Bug 201262 is somehow related to this one too.


Reproducible: Always

Steps to Reproduce:
0. From a page (like startup/<about:>) with no history (= back/forward buttons
disabled)
1. Load the testcase
2. Press the Back button

Actual Results:  
In v1.4rc1 (after 201108), as in v1.3.1 (before 201108), [no (K) "regression']
the previous page (the one from step 0) is displayed.


Expected Results:  
I wonder:
this may be the intended behaviour: you might say so and mark this bug as
WontFix (!) or Invalid (?);
or this may be a true (K) '4xp' bug.

[Netscape® Communicator 4.8 : en-20020722]

The previous (left) _frame_ (<vide_g.html>) is displayed ("correctly" replacing
<frame2_g.html>).

NB: Another 'Back' returns "correctly" to the page from step 0.


I'll add (b.) bug 59387: the current bug might be a duplicate of another one
there, but this one "has" an explicit testcase :-)

For an end-user, the current behaviour may be better !?
For a more power/technical user, the '4xp' behaviour could be more useful !?
May be, a good solution would be to keep the current behaviour ("page back") as
default, and add a "frame back", more/less like bug 185793 RFE !!? (you may
confirm that other bug, and mark the current one as duplicate of it (or
dependent for the time being)...)


[Microsoft Internet Explorer, version 3.0 (4.70.1158)]

Irrelevent (lake of JS support !!?): it doesn't load <frame2_g.html> in the
first place.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> 1. Load the testcase

Which testcase?  The other bug has a zip with a bunch of files in it; which of
those are relevant?

I can't figure out what the expected result is for the testcase based on the
opening comment of this bug, so you mant to clarify that as well.

Comment 2

[Frank Wein [:mcsmurf]]

Probably gautheri means this bug:
1. Go to any site you like (slashdot.org or whatever)
2. Load my testcase from http://mitglied.lycos.de/mcsmurf/testcase3/testcase.html
(have JavaScript enabled)
3. Wait 5 seconds

Normally it should go back one site in the lower frame, but it goes back to the
page you loaded in 1. If you insert a timeout so that the lower frame can be
loaded completely, then it goes one site back in the lower frame.

Comment 3

[Boris Zbarsky [:bzbarsky]]

That "testcase" has hundreds of lines of JS attached to it.  If you give me an
actual testcase (i.e. something debuggable) I can try to take a look at it.  A
good start would be not linking to external ad server JS....  A second good
start would be eliminating everything you can while still demonstrating the bug.

Comment 4

[Frank Wein [:mcsmurf]]

(In reply to comment #3)
> That "testcase" has hundreds of lines of JS attached to it.  If you give me an
> actual testcase (i.e. something debuggable) I can try to take a look at it.  A
> good start would be not linking to external ad server JS....  A second good
> start would be eliminating everything you can while still demonstrating the bug.

Actually this testcase had one only 2 lines JS in it, the rest is all ads from
my webspace provider :/, I'll attach the testcase here.

Comment 5

[Frank Wein [:mcsmurf]]

Attachment: Testcase

Extract the testcase and open testcase.html

Comment 6

[Boris Zbarsky [:bzbarsky]]

So the issue here is that you're resetting the url on the bottom frame before it
even starts loading the first URL (that is, before it receives an HTTP response
to the request for the first URL).  Since session history entries don't get
created for loads that never really got content, there's no session history
entry for that first URL.  Which is the way we want it to be, I think...

Comment 7

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040421] (<-- 1.7rc1 !)
(W98SE)

(In reply to comment #1)
> > 1. Load the testcase
> 
> Which testcase?  The other bug has a zip with a bunch of files in it; which of
> those are relevant?

Based on bug 201108 comment 4,
and your nice use of the 'jar:' syntax:
the entry point is
<jar:http://bugzilla.mozilla.org/attachment.cgi?id=119880&action=view!/201108_ReducedTestcase_SG1/index.asp.html>.

> I can't figure out what the expected result is for the testcase based on the
> opening comment of this bug, so you mant to clarify that as well.

1. Open a new Tab/Window, load <about:> (for example)
2. Load my testcase with the previously given URL
3a. Accept the two alert()
3b. While doing 3a, check that you see vide_g.html content in the left frame.
(this works only the first time per tab: not with next/back after that)
4. Press Back

5. You're back to step 1 URL;
Whereas Netscape v4.8 takes a second Back to go there: (need to unzip and access
the testcase as local files)
the first Back only changes back the left frame from frame2_g.html to vide_g.html.

This bug is about whether or not MozillaV1 should behave as NetscapeV4 does:
I would believe so, not liking to know that a frame can load and be replaced,
without me having any mean to know/see/access it (at least afterward)...
That's the question.

Comment 8

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)
> So the issue here is that you're resetting the url on the bottom frame before it
> even starts loading the first URL (that is, before it receives an HTTP response

That makes sense in general :-)
yet it doesn't seem to apply to my step 3b :-(

Main difference here between Frank's testcase and mine: his has got a long
bottom(2) frame replaced from a short(1) top frame;
whereas mine has a short left(1) frame replaced from a little less short
right(2) frame.

Tonight, and with the jar: URL,
I can even see the left frame content, then the rigth frame content, with a
(network) delay between the two: the left frame load seems to have completed
successfully in due time.

What do you think ?

Comment 9

[Boris Zbarsky [:bzbarsky]]

I think that changes to a frame's location before its parent has finished
loading are generally rather confused.  See the mLSHE check in
nsDocShell::AddChildSHEntry -- that lumps together all child stuff that happens
before the frame has loaded.

Someone just needs to take an axe to this and nsDocShell::CloneAndReplace (which
should arguably be pushed into the session history apis and have a different name).