Closed Bug 1160 Opened 26 years ago Closed 25 years ago

Apprunner window paints incorrectly

Categories

(Core Graveyard :: GFX, defect, P1)

Product:
Core Graveyard
Component:
GFX
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: chofmann, Assigned: beard)

References

(
URL
)

Details

(Whiteboard: TESTCASE erin@imaginet.com)

Attachments

(5 files)

test case for 1160
(deleted), text/plain
Details
new test case
(deleted), text/plain
Details
html test page
(deleted), text/html
Details
left frame
(deleted), text/html
Details
right frame
(deleted), text/html
Details
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.
Assignee: scullin → troy
Assignee: troy → karnaze
Component: Viewer App → HTMLFrames
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.
Status: NEW → ASSIGNED
Priority: P2 → P1
Summary: frame window doesn't show correct contents → ss:frame window doesn't show correct contents
Putting ss: in Summary.
*** Bug 1490 has been marked as a duplicate of this bug. ***
Assignee: karnaze → rpotts
Status: ASSIGNED → NEW
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>
Summary: ss:frame window doesn't show correct contents → frame window doesn't show correct contents
Taking off ss: list per bug mtg today.
Assignee: rpotts → troy
Re-assigned to troy@netscape.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?
Assignee: troy → rpotts
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...
Assignee: rpotts → gagan
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...
Assignee: gagan → ebina
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
Status: NEW → ASSIGNED
Component: HTMLFrames → Networking Library
QA Contact: 4082 → 3819
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">
Assignee: ebina → jevering
Status: ASSIGNED → NEW
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..
Target Milestone: M4 → M5
move to m5
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
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
Status: RESOLVED → REOPENED
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.
Target Milestone: M5 → M6
moving to m6
Target Milestone: M6 → M7
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
Resolution: WORKSFORME → ---
Target Milestone: M7 → M8
*** Bug 8316 has been marked as a duplicate of this bug. ***
Assignee: jevering → karnaze
Status: REOPENED → NEW
Component: Networking Library → HTMLFrames
Target Milestone: M8 → M9
this may be a dup of several frames bugs I read recently. moving off the m8 redar
Whiteboard: makingtest erin@imaginet.com
Attached file test case for 1160 (deleted) —
Attached file new test case (deleted) —
Attached file html test page (deleted) —
Attached file left frame (deleted) —
Attached file right frame (deleted) —
Whiteboard: makingtest erin@imaginet.com → test case erin@imaginet.com
I had no problems when I checked this bug out.
Whiteboard: test case erin@imaginet.com → TESTCASE erin@imaginet.com
Assignee: karnaze → pollmann
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.
Assignee: pollmann → beard
Component: HTMLFrames → Compositor
OS: Windows 95 → All
Hardware: PC → All
Summary: frame window doesn't show correct contents → Apprunner window paints incorrectly
Target Milestone: M9
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.
Status: NEW → ASSIGNED
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.
Target Milestone: M13
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
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
QA Contact: paulmac → petersen
With the April 20th build (2000072011), I'm not able to reproduce the original problem.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: