145222 - Reload frameset broken as of 7th May

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect)

Description

[Ere Maijala (slow)]

Reload button and F5 used to reload the current content of the frameset. This
worked fine in 20020506 but is broken in 20020507. Now it will reload the whole
frameset effectively loading the initial frames of the frameset. I didn't see
any checkins regarding this, but Bug 125372 looks suspicious. I consider this
regression.

Comment 1

[Radha on family leave (not reading bugmail)]

Is there a url or testcase for this problem? Is this still a issue?

Comment 2

[Ere Maijala (slow)]

Attachment: Frameset test files (zip)

A freshly created frameset test package (sorry about some ugly code). Unzip to
a folder and load index.html into Mozilla. Observe two links on the left frame.
Click on the second link "Test". Press reload. Mozilla will change to "Main"
page. I would expect it to stay on the current frame aas it did before.

Comment 3

[Radha on family leave (not reading bugmail)]

I can't reproduce this in the latest Mozilla 1.0 RC3 builds. 

Comment 4

[Ere Maijala (slow)]

Yes, I haven't tried branch builds. I'm running only trunk builds. At least bug
125372 which I suspect has been checked in only into trunk (according to the
bug). I'll check again with a recent trunk build again.

Comment 5

[Ere Maijala (slow)]

I've tried with trunk build 20020531 (could not get a newer one as
ftp.mozilla.org is horked). I can still reproduce the problem every time, but
the reliable way to reproduce it with the attached test case is:
1. open a new browser window
2. load index.html 
3. do a complete reload using Ctrl-F5 
4. click main
5. click test
6. do a normal reload using reload button or F5 -> switches to main page

Please note that this is complicated only in this test case. In our internal
system it happens all the time.

Comment 6

[Felix Miata]

Using 2002060608 OS/2 trunk

When I click attachment "frameset test files", Mozilla wants to save
"attachment.cgi", so I don't know how to execute the recreate. I've been trying
to find an existing bug that describes behavior I see and don't know if maybe
bug 48422 or this qualifies. Here's what I see:

To reproduce:
1-load a frames page (e.g. http://mrmazda.members.atlantic.net/sats/satcharts.html)
2-click a link that causes another URL to open in the main frame window (e.g. T7)
3-Go to prefs and switch between page colors and my colors

Actual behavior:
1-Page displays the result of step 1 above

Expected behavior:
1-Page displays the result of step 2 above

Comment 7

[Mike Kaply [:mkaply]]

You can just name the attachment test.zip and unzip it.

Comment 8

[Felix Miata]

For me in OS/2 with the testcase Ctrl-F5 reloads main, while ordinary reload
leaves showing test, so this is not windows only.

Please change OS to all, as I don't have that power.

Should I file a separate bug for the behavior in comment 6?

Comment 9

[Ere Maijala (slow)]

Comment on attachment 85482 [details]
Frameset test files (zip)

It's a zip file.

Comment 10

[Ere Maijala (slow)]

If F5 reloads the current content, it works as expected. Sometimes (as in
comment #5) it will load the main page, which is unexpected. 

I'm not sure if Ctrl-F5 should load the main page or not, but I have a feeling
that its behavior has not changed.

Comment 11

[Radha on family leave (not reading bugmail)]

I can't reproduce this bug in the trunk as well as in the branch. 

Comment 12

[Ere Maijala (slow)]

Crap, the testcase is broken again, but the real problem is still there. I'll
try to rebuild the test case again. Anyway, it still fails miserably for me in
the "real life".

Comment 13

[Ere Maijala (slow)]

It seems to matter if I use local files or a server. Point to
http://kala.atp.fi/~ere/frametest/. It fails for me everytime simply by clicking
Test and then reload button. Sometimes the Back button seems to die also. Trunk
build 20020626 WinXP.

Comment 14

[Radha on family leave (not reading bugmail)]

I tried the website in today's trunk on NT and linux. I can't reproduce this. Do
you have cache enabled? Claudius, can you confirm this is indeed WFM. Thanks.

Comment 15

[Ere Maijala (slow)]

Okay, so my testcase still doesn't work in normal situations, but the problem
still exists. I'll try again and test the testcase better.

Comment 16

[Ere Maijala (slow)]

Now, hopefully, I've found good places to test this. Point to
http://kinnula.kirjas.to, click "Tiedonhaku" from the left frame, then click
reload. For example with 20020505 build it will beautifully reload the current
frames, but recent builds change to the first page. I tried this with fresh
newly created profiles.

Comment 17

[Daniel Dvorkin]

I've observed this behavior under MacOS X using 20020722.  FWIW.

Comment 18

[Radha on family leave (not reading bugmail)]

This is probably related to bug 160869

Comment 19

[frans funnekotter]

Another place to encounter this bug: www.conrad.nl get some product info, select
a product, press reload and you return to www.conrad.nl as if you typed it in
the location bar. The back button has same behaviour: you won't go back one
page, but you'll return to the first page of the frameset.

Comment 20

[Radha on family leave (not reading bugmail)]

In http://kinnula.kirjas.to, the onclick() handler and the href confuse session
history. when you click on "Tiedonhaku", the onclick handler triggers and
"laita.asp?sivu1=tiedonhaku&kirjauduttu=0&lainat=0&varaukset=0&maksut=0" begins
to load. But this is intercepted by the url provided in <a href="sanahaku.asp">
and therefore sanahaku shows up. Looking to see if any particular checkin caused
this change in behavior.

Comment 21

[Radha on family leave (not reading bugmail)]

Is there any particular build in which this problem started showing up?

Comment 22

[Ere Maijala (slow)]

See the summary and initial comment. Trunk builds.

Now that you told me the reason for this, I'm not sure if this is the same
problem I originally reported, because the other system we have problems with is
not using an onclick handler. I don't know if this is a separate issue then and
maybe it has not broken between 6th and 7th May. The original issue might be
more related to bug 160869 as you said.

Comment 23

[Radha on family leave (not reading bugmail)]

onclick handler and href in a link will cause a unpredictable race condition and
what gets shown depends on which url comes for loading later.  please see the
latest comments to bug 157820, regarding the usage of oclick handler and href in
a link. Also, I'm not able to reproduce the problem described in comment # 16 in
latest trunk builds.