Closed
Bug 181407
Opened 23 years ago
Closed 22 years ago
Reload on a frameset page reloads initial rather than current frame
Categories
(Core :: DOM: Navigation, defect, P3)
Core
DOM: Navigation
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: sdagley, Assigned: sfraser_bugs)
References
()
Details
Attachments
(1 file)
|
98 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20021105 Netscape/7.01
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20021105 Netscape/7.01
If you're browsing a page that uses frames doing a reload results in the initial
frameset being reloaded rather than the frame data displayed when the reload is
done. This also seems to do something wonky to the back/forward history.
Reproducible: Always
Steps to Reproduce:
1. Load the test page
2. Click CAR WASHES link in bottom left frame.
3. Click P21S BODYWORK... link in the bottom left frame
4. Click Reload in the toolbar.
Actual Results:
I get the initial frameset reloaded.
Expected Results:
The page that was displayed when Reload was clicked should have been reloaded
(Mozilla does reload the correct frameset)
| Reporter | ||
Comment 1•23 years ago
|
||
I think this is what denver.dan@verizon.net was reporting on chimerafeedback
| Assignee | ||
Comment 2•23 years ago
|
||
Mozilla goes back to the initial frame on reload, for me. When I try to reload
the page in IE, I get an error about it not being able to load one of the
frames. Omniweb does the same as Mozilla.
| Reporter | ||
Comment 3•23 years ago
|
||
The Mozilla build I don't see a problme on is a MOZILLA_1_0_BRANCH build.
I checked a couple of other framed sites and they exhibit the same behavior:
http://www.911t.org/options/
http://www.maui.net/~mauinews/framnews.htm
Comment 4•23 years ago
|
||
This bug also occurs in current builds of Mozilla 1.2.
Comment 5•23 years ago
|
||
I always test this with HTML generated by javadoc and this works fine with
Mozilla 1.0-1.2 but it does not work with Chimera 0.6.
| Assignee | ||
Updated•23 years ago
|
Severity: major → normal
Priority: -- → P3
Updated•23 years ago
|
Target Milestone: --- → Future
| Reporter | ||
Comment 6•23 years ago
|
||
Hey, not to be a dick but targeting for FUTURE does not strike me as the right
resolution for this. It's potentially a dataloss regression (think multi-page
form being filled out in a frameset) and it is _NOT_ Chimera specific. It
_used_ to work but even the Mozilla trunk is showing the same problem now
according to comment #4.
Target Milestone: Future → ---
Comment 7•23 years ago
|
||
What Steve said. It definitely shows up in the Mozilla trunk under OS X and is
IMO a pretty serious bug. The last place it _doesn't_ show up seems to be 1.02 ...
Comment 8•23 years ago
|
||
*** Bug 182913 has been marked as a duplicate of this bug. ***
Comment 9•23 years ago
|
||
I see the bug on OS/2 version of Mozilla (bug 182913)
Shouldn't we change component/OS to Browser/All ?
Comment 10•23 years ago
|
||
Changing Component/OS according to comments #6, 7, 9
Component: History → History: Session
OS: MacOS X → All
Product: Chimera → Browser
Hardware: Macintosh → All
Version: unspecified → Trunk
Comment 11•23 years ago
|
||
Can I use userHTMLBindings.xml somehow to rebind ctrl-R to the reloadFrame
command instead? What's the command name for reload frame (it's on the context
menu)?
Updated•23 years ago
|
Target Milestone: --- → Future
Comment 12•22 years ago
|
||
Comment 13•22 years ago
|
||
With that testcase, this bug worksforme in a current build. Click links in
either frame, submit the google search form, whatever. Then reload. The
subframes are reloaded with whatever was in them before you hit reload, not with
the initial pages.
I've also tested the dup bug and it worksforme as well.
Is this still an issue?
Comment 14•22 years ago
|
||
Boris, the procedure in bug 182913 comment 1 still shows the bug.
Linux build 2004052606 here
Another example:
1. open http://members.aol.com/DrMWEcker/REC.html
2. scroll down the right frame and stop at some place near the bottom
3. click Reload
4. the right frame scrolling position is reset at the top
Comment 15•22 years ago
|
||
Max, that's not this bug as it's originally reported and it's not the same bug
as reported in bug 182913 comment 0. We do have an existing bug report for that
bug (lack of scroll state restoration in subframes in general, actually, which
is quite distinct from not loading the right page in the subframe on a history
load).
Marking worksforme, if that's the only remaining issue.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Component: History: Session → Document Navigation
QA Contact: winnie → docshell
Comment 16•9 years ago
|
||
Not sure if I should be re-opening an old issue, but has this bug been re-introduced in v54?
I use a work intranet site daily. The site is in a frameset. If I press F5 to reload the frame contents, Firefox will instead reload the frameset homepage rather than the frame that is being viewed.
This behaviour is being replicated on all PCs thats have been updated to v54.
Comment 17•9 years ago
|
||
Best to file a new bug, ideally with a link to a testcase. Please cc me on the new bug, and I'll take a look.
Comment 18•9 years ago
|
||
Cheers Boris,
New Bug 1375833
You need to log in
before you can comment on or make changes to this bug.
Description
•