Apprunner window paints incorrectly

VERIFIED WORKSFORME

Status

Core Graveyard
GFX
P1
normal
VERIFIED WORKSFORME
19 years ago
9 years ago

People

(Reporter: chris hofmann, Assigned: Patrick C. Beard)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: TESTCASE erin@imaginet.com, URL)

Attachments

(5 attachments)

(Reporter)

Description

19 years ago
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

19 years ago
using ftp://ftp.mozilla.org/pub/newlayout/nightly/98-10-19/
on win95 laptop

Updated

19 years ago
Assignee: scullin → troy

Updated

19 years ago
Assignee: troy → karnaze
Component: Viewer App → HTMLFrames

Comment 2

19 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

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Priority: P2 → P1
Summary: frame window doesn't show correct contents → ss:frame window doesn't show correct contents

Comment 3

19 years ago
Putting ss: in Summary.

Comment 4

19 years ago
*** Bug 1490 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Assignee: karnaze → rpotts
Status: ASSIGNED → NEW

Comment 5

19 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>

Updated

19 years ago
Summary: ss:frame window doesn't show correct contents → frame window doesn't show correct contents

Comment 6

19 years ago
Taking off ss: list per bug mtg today.

Updated

19 years ago
Assignee: rpotts → troy

Comment 7

19 years ago
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?

Updated

19 years ago
Assignee: troy → rpotts

Comment 8

19 years ago
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

19 years ago
Assignee: rpotts → gagan

Comment 9

19 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...

Updated

19 years ago
Assignee: gagan → ebina

Comment 10

19 years ago
Eric's our new strems/convertors man!

Comment 11

19 years ago
Setting all current Open/Normal to M4.

Comment 12

19 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

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Component: HTMLFrames → Networking Library
QA Contact: 4082 → 3819

Comment 13

19 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

19 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

19 years ago
Assignee: ebina → jevering
Status: ASSIGNED → NEW
(Reporter)

Comment 15

19 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

19 years ago
Target Milestone: M4 → M5
(Reporter)

Comment 16

19 years ago
move to m5

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 17

19 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

19 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 18

19 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

19 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

19 years ago
Seems to work on viewer.  Verified that it is apprunner specific.

Comment 21

19 years ago
Disabling sidebar in the navigator.xul file seems to allow it to work properly.
Must be something related to iframe.
(Reporter)

Updated

19 years ago
Target Milestone: M5 → M6
(Reporter)

Comment 22

19 years ago
moving to m6
(Reporter)

Updated

19 years ago
Target Milestone: M6 → M7
(Reporter)

Comment 23

19 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

19 years ago
Resolution: WORKSFORME → ---

Updated

19 years ago
Target Milestone: M7 → M8

Comment 24

19 years ago
*** Bug 8316 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

19 years ago
Assignee: jevering → karnaze
Status: REOPENED → NEW
Component: Networking Library → HTMLFrames
Target Milestone: M8 → M9
(Reporter)

Comment 25

19 years ago
this may be a dup of several frames bugs I read recently.
moving off the m8 redar

Updated

19 years ago
Whiteboard: makingtest erin@imaginet.com

Comment 26

19 years ago
Created attachment 830 [details]
test case for 1160

Comment 27

19 years ago
Created attachment 836 [details]
new test case

Comment 28

19 years ago
Created attachment 844 [details]
html test page

Comment 29

19 years ago
Created attachment 845 [details]
left frame

Comment 30

19 years ago
Created attachment 846 [details]
right frame

Updated

19 years ago
Whiteboard: makingtest erin@imaginet.com → test case erin@imaginet.com

Comment 31

19 years ago
I had no problems when I checked this bug out.

Updated

19 years ago
Whiteboard: test case erin@imaginet.com → TESTCASE erin@imaginet.com

Updated

19 years ago
Assignee: karnaze → pollmann

Comment 32

19 years ago
Reassigning to Eric.

Comment 33

19 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

19 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

19 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

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 35

19 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

18 years ago
Target Milestone: M13
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago18 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 36

18 years ago
Other than latent images remaining when document loads slowly, I don't see any
remaining problems in the test cases.

Comment 37

18 years ago
Updating QA Contact from paulmac to petersen
QA Contact: paulmac → petersen

Comment 38

18 years ago
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.