Closed
Bug 1160
Opened 26 years ago
Closed 25 years ago
Apprunner window paints incorrectly
Categories
(Core Graveyard :: GFX, defect, P1)
Core Graveyard
GFX
Tracking
(Not tracked)
VERIFIED
WORKSFORME
M13
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.
Reporter | ||
Comment 1•26 years ago
|
||
using ftp://ftp.mozilla.org/pub/newlayout/nightly/98-10-19/
on win95 laptop
Updated•26 years ago
|
Assignee: troy → karnaze
Component: Viewer App → HTMLFrames
Comment 2•26 years ago
|
||
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.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Priority: P2 → P1
Summary: frame window doesn't show correct contents → ss:frame window doesn't show correct contents
Updated•26 years ago
|
Assignee: karnaze → rpotts
Status: ASSIGNED → NEW
Comment 5•26 years ago
|
||
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
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?
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...
Updated•26 years ago
|
Assignee: rpotts → gagan
Comment 9•26 years ago
|
||
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...
Comment 10•26 years ago
|
||
Eric's our new strems/convertors man!
Comment 11•26 years ago
|
||
Setting all current Open/Normal to M4.
Comment 12•26 years ago
|
||
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Comment 13•26 years ago
|
||
qa contact to paulmac....component to netlib as per comments this appears to not
be a frames problem but rather netlib
Comment 14•26 years ago
|
||
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">
Reporter | ||
Updated•26 years ago
|
Assignee: ebina → jevering
Status: ASSIGNED → NEW
Reporter | ||
Comment 15•26 years ago
|
||
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..
Reporter | ||
Updated•26 years ago
|
Target Milestone: M4 → M5
Reporter | ||
Comment 16•26 years ago
|
||
move to m5
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
Comment 17•26 years ago
|
||
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
Reporter | ||
Updated•26 years ago
|
Status: RESOLVED → REOPENED
Reporter | ||
Comment 18•26 years ago
|
||
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.
Comment 19•26 years ago
|
||
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.
Comment 20•26 years ago
|
||
Seems to work on viewer. Verified that it is apprunner specific.
Comment 21•26 years ago
|
||
Disabling sidebar in the navigator.xul file seems to allow it to work properly.
Must be something related to iframe.
Reporter | ||
Updated•26 years ago
|
Target Milestone: M5 → M6
Reporter | ||
Comment 22•26 years ago
|
||
moving to m6
Reporter | ||
Updated•26 years ago
|
Target Milestone: M6 → M7
Reporter | ||
Comment 23•26 years ago
|
||
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
Updated•26 years ago
|
Target Milestone: M7 → M8
Comment 24•26 years ago
|
||
*** Bug 8316 has been marked as a duplicate of this bug. ***
Reporter | ||
Updated•26 years ago
|
Assignee: jevering → karnaze
Status: REOPENED → NEW
Component: Networking Library → HTMLFrames
Target Milestone: M8 → M9
Reporter | ||
Comment 25•26 years ago
|
||
this may be a dup of several frames bugs I read recently.
moving off the m8 redar
Updated•26 years ago
|
Whiteboard: makingtest erin@imaginet.com
Comment 26•26 years ago
|
||
Comment 27•26 years ago
|
||
Comment 28•26 years ago
|
||
Comment 29•26 years ago
|
||
Comment 30•26 years ago
|
||
Updated•26 years ago
|
Whiteboard: makingtest erin@imaginet.com → test case erin@imaginet.com
Comment 31•26 years ago
|
||
I had no problems when I checked this bug out.
Updated•26 years ago
|
Whiteboard: test case erin@imaginet.com → TESTCASE erin@imaginet.com
Updated•26 years ago
|
Assignee: karnaze → pollmann
Comment 32•26 years ago
|
||
Reassigning to Eric.
Comment 33•26 years ago
|
||
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.
Updated•26 years ago
|
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
Comment 34•26 years ago
|
||
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.
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 35•26 years ago
|
||
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.
Assignee | ||
Updated•26 years ago
|
Target Milestone: M13
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Comment 36•25 years ago
|
||
Other than latent images remaining when document loads slowly, I don't see any
remaining problems in the test cases.
Comment 37•25 years ago
|
||
Updating QA Contact from paulmac to petersen
QA Contact: paulmac → petersen
Comment 38•25 years ago
|
||
With the April 20th build (2000072011), I'm not able to reproduce the original
problem.
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•