Closed Bug 1160 Opened 26 years ago Closed 25 years ago

Apprunner window paints incorrectly

Categories

(Core Graveyard :: GFX, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: chofmann, Assigned: beard)

References

()

Details

(Whiteboard: TESTCASE erin@imaginet.com)

Attachments

(5 files)

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
Attached file new test case
Attached file html test page
Attached file left frame
Attached file right frame
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 ago25 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.