Closed
Bug 4947
Opened 26 years ago
Closed 25 years ago
Loading frameset causes current page to render in frameset
Categories
(Core Graveyard :: Embedding: APIs, defect, P3)
Tracking
(Not tracked)
M10
People
(Reporter: mozilla, Assigned: nisheeth_mozilla)
References
Details
(Whiteboard: [Perf])
If one visits any page, and then loads a frameset page, the frameset is drawn
before the content of the frameset is loaded. The orignal page is then loaded
into the framset for a brief instant. Aesthetically unpleasing.
REPRODUCE:
1. Load any URL into apprunner.
2. Manually enter a URL of a known frameset into the location box and hit ENTER.
3. Watch as the frameset is drawn and the contents of the URL #1 are drawn into
each frame for a brief instant.
USING: Nightly build (4-10-99 Win32).
Updated•26 years ago
|
Assignee: karnaze → hyatt
Comment 1•26 years ago
|
||
I went to sample 6 and then to sample 9 which is a frameset document. I didn't
see the problem on 4/10 apprunner or 4/10 viewer. Reassigning to David to take a
further look.
Updated•26 years ago
|
Assignee: hyatt → karnaze
Comment 2•26 years ago
|
||
The bug description isn't quite accurate. Chris, in both viewer and apprunner
(I see it in both), there's a noticeable delay between the time the initial
splitter bars are drawn for the new frameset and the time that the frames are
actually filled in with data, i.e., the splitters appear, but the
subframes' contents aren't loaded yet, and the old page isn't being blown away
by an EraseBackground call in the subframes until the body tag is being
encountered in the subframes' subdocuments.
Maybe what needs to happen is that you need to go ahead and wipe a new
webshell's view and fill it with a background color or something when it is
first constructed.
I suspect that as performance improves, this bug will become a non-issue anyway.
For me, sample #9 takes a really really long time to load, and I think that's
really the only reason I have time to see all of this stuff.
Anyway, I see it in viewer and in apprunner, so I'm bouncing it back to you,
Chris. :)
Updated•26 years ago
|
Assignee: karnaze → nisheeth
Comment 3•26 years ago
|
||
Reassigning to Nisheeth, since it sounds more like a web shell problem.
Reporter | ||
Comment 4•26 years ago
|
||
I am a little mystified here at the inability of others to see this. I am trying
it with the 4-10-99 build as I write this. It is most defnitely reloading the
contents of the original page into each frame cell BEFORE loading the actual
content of the frames.
Reporter | ||
Comment 5•26 years ago
|
||
Screenshot captured. Take a look at
http://holly.colostate.edu/~jerbaker/Mozilla/mozilla_bug.gif
Confirming. It doesn't seem to clear the page before relodng the next one.
Checked using Win98.
Comment 7•25 years ago
|
||
I'm pretty sure this is related... when using the target=_top it first copies
the original screen into each frame, then it starts over. (See
http://www.novagate.com/~jsteenhagen/Mozilla/4947.html ) (Windows 98)
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Component: HTMLFrames → Embedding APIs
Target Milestone: M6
Assignee | ||
Comment 8•25 years ago
|
||
Accepting bug. Setting component to Embedding APIs and target milestone to
M6...
Assignee | ||
Updated•25 years ago
|
Target Milestone: M6 → M8
Assignee | ||
Comment 9•25 years ago
|
||
Moving bug to M8...
Comment 10•25 years ago
|
||
Putting on [Perf] radar
Assignee | ||
Updated•25 years ago
|
Target Milestone: M8 → M10
Assignee | ||
Comment 11•25 years ago
|
||
Distibuting bugs over milestones... This one goes to M10.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 12•25 years ago
|
||
*** This bug has been marked as a duplicate of 5849 ***
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 13•25 years ago
|
||
verified dup
Reporter | ||
Comment 14•22 years ago
|
||
Mass removing self from CC list.
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•