421507 - IFrame loses original contents after browser reload

Status: RESOLVED INVALID

(Core :: DOM: Navigation, defect)

Description

[Mike Moening]

Attachment: testcase

This bug only exists on the current truck (Firefox 3).
See attached test case for details.

Not sure if this is desired behavior or not.  However FF 2.x does not work the same way.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I can't reproduce this.  I click the link, then I click Ctrl-R.  I see the original text.

Current-ish debug Firefox on Linux.

Comment 2

[Mike Moening]

I'm on windows.
How about clicking refresh with the mouse? 
I'll pull down the trunk and re-build again. Possibly fixed in last 2-3 days?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Same thing clicking with the mouse.

My exact pull date is MOZ_CO_DATE="Sat Mar 1 01:10:24 CST 2008".

Comment 4

[Mike Moening]

After a fresh pull of HEAD and build today this still fails on FF3 trunk with Windows 2000 lastest SP.

My of my guys downloaded FF3 Beta 3 and reproduced the problem on Windows XP.
However, we did make it fail once on FF2 2.0.0.12.
Seems it is related to either loading from file:// or http:// 
Differing ways of loading may produce inconsistent results.

We've had 100% failure rates on FF3 Beta 3 and Trunk in both Windows 2000 and XP.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Ah, yeah.  This does behave differently from file://.  At that point I see the same behavior trunk and branch (or rather immediately pre-branch).

I have no idea why the difference....  Session history is a bloody mess.

Comment 6

[Boris Zbarsky [:bzbarsky]]

OK, so from file:// I get google when I reload.  That's more or less expected behavior: see bug 279048.

Comment 7

[Hallvord R. M. Steen [:hallvors]]

If bz says this is expected, can we close this bug?

Comment 8

[Boris Zbarsky [:bzbarsky]]

I think so, yeah.  Though this stuff is still a bloody mess, only now with a spec that may not be web-compatible.  ;)