when trying to run browser buster on say a 30 second cycle the upper lefthand frame does not correct contents. looks like some mush from the previous frame.
using ftp://ftp.mozilla.org/pub/newlayout/nightly/98-10-19/ on win95 laptop
Sounds like a frames issue. Reassigning to Chris; moving Troy to the cc field; setting component to "HTMLFrames." I've noticed this sort of behavior on other frame sites when loading new framesets.
Putting ss: in Summary.
*** Bug 1490 has been marked as a duplicate of this bug. ***
The following html (you need to supply simple dummy files called url.1, t.html, count.html) illustrates a problem with loading frame no1. It has an ".1" extension that the viewer is not recognizing. If it is replaced with a ".html" extension, the viewer can handle it. I don't know why Nav can load it. Nav can't load for example http://americanmaid/url.1 I am reassigning this to Rick Potts, but it might be easier if the browser buster page were changed to use an html extension. <head> <title>page loader test page url.136 </title> <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> <meta http-equiv="refresh" content="30"> </head> <frameset rows="40,*"> <frameset cols="75%,15%,10%"> <FRAME name=no1 SRC="url.1"> <FRAME name=no2 SRC="t.html"> <FRAME name=no3 SRC="count.html"> </FRAMESET> <FRAME name=no4 SRC="http://home.netscape.com"> </FRAMESET>
Taking off ss: list per bug mtg today.
Re-assigned to email@example.com. Troy, who should get this bug? It doesn't appear to be an xpapps issue. And is it still a bug in the brave new world?
Gramps, the reason Chris Karnaze assigtned it to Rick Potts in the first case isbecause he thought it was Web shell related. It definitely isn't core layout related...
From karnaze's comments it sounds like the document loader is being handed a stream with an unknown content-type. Most likely, the URL does not have a .html extension. The old Nav4 netlib did a better job of MIME-type guessing than the current one does now... So, since the document loader can't determine the content type, it fails to create a ContentViewer for the frame. This results in a window which does not process Paint messages and hence garbage from the previous document sticks around :-( I'm moving this bug over to the netlib group... Once the content type is known, the document loader should do the right thing (tm). The other bug is really that an "unknown content" ContentViewer should be created for the webshell to prevent garbage from sticking around...
Eric's our new strems/convertors man!
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
qa contact to paulmac....component to netlib as per comments this appears to not be a frames problem but rather netlib
Ok, I tried to check this bug out both on the URL listed for browser buster, and using the test frameset provided in the description text. On both viewer and apprunner (on Linux) the upper left frame loads fine. Since neither viewer or apprunner seem to allow the auto-refresh every 30 seconds, I can't test if it would somehow fail on subsequent loads. Right now there appears to be no bug to me other than that viewer and apprunner don't honor: <meta http-equiv="refresh" content="30">
move from ebina to jevering. looks like the refresh is now working, but I crash on the 3 page load. should be able to post a talkback stack trace later..
move to m5
I have tested this with the apprunner build from 04.27 and it seems to refresh ok. It doesn't crash for my either. running on Win98
click on one of the first links shown on the http://grok/tests/page_loader/about.html like http://grok/tests/page_loader/test_url_25.html a few updates occur, but the frames in the content window are horked and then we crash.
Yes, that is strange. It must have something to do with the URL that is being loaded. I see much different behaviour on http://grok/tests/page_loader/test_url_15.html. I'll look into it more.
Seems to work on viewer. Verified that it is apprunner specific.
Disabling sidebar in the navigator.xul file seems to allow it to work properly. Must be something related to iframe.
moving to m6
big improvements in m6. I now have run up to 60 page loads, but still see the top frames duped at each reload. it seem to fix itself now which is a bit of improvement but still ugly
*** Bug 8316 has been marked as a duplicate of this bug. ***
this may be a dup of several frames bugs I read recently. moving off the m8 redar
I had no problems when I checked this bug out.
Reassigning to Eric.
This is not a frameset specific bug. If you load any sufficiently large page in apprunner, you will see the toolbar copied temorarily into the page area, then painted over by the page. For example, start up apprunner. Watch as www.mozillazine.org loads. If your machine is sufficiently slow you will see this bug even though there are no frames or iframes in the page.
Patrick, is this a compositor issue? Here's how to reproduce this bug: - Start apprunner. - Resize the window to as wide as possible. As the window paints, the damaged area will temporarily show an vertically offset copy of the page, which will then repaint into the correct position. I've been seeing this bug on Linux and Windows in current builds, but haven't checked Mac.
This is realy by design that it does this. Pierre has played with erasing the area when an update occurs but no content exists for it yet. There should really be some kind of default painting behavior that occurs when no content exists yet, that stops happening when content is available. It's a subtle problem.
Other than latent images remaining when document loads slowly, I don't see any remaining problems in the test cases.
Updating QA Contact from paulmac to petersen
With the April 20th build (2000072011), I'm not able to reproduce the original problem.