Closed Bug 1643 Opened 26 years ago Closed 25 years ago

browser buster still not running

Categories

(Core Graveyard :: Viewer App, defect, P1)

Product:
Core Graveyard
Component:
Viewer App
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED INVALID

People

(Reporter: glynn, Assigned: rickg)

References

(
URL
)

Details

Nov 24 build, raptor demo

1.  Launch xpviewer on NT 4.0 or win95 machine, go to http://grok/tests/
page_loader and try to run the top 100 sites

•  They will not run....I let the machine sit overnight and was greeted this
morning by a running out of virtual memory alert, and still no progress.  backed
up by the autorun report saying it failed as well in 6 seconds.
Summary: ss: Virtual memory suckage - trying to run grok page loader → Virtual memory suckage - trying to run grok page loader
Taking off ss: list per bug mtg today.
Status: NEW → ASSIGNED
Assignee: rickg → gagan
Status: ASSIGNED → NEW
The <PRE><HR> bug reported here is fixed, but FTP access is still slow.
Please look into this.
xpviewer is dead.  glynn, please try this against latest viewer and post results
here for gagan.
Severity: critical → normal
Status: NEW → ASSIGNED
There are a lot of memory leaks in general. I will look for those in Netlib, but
I think we need to do this excercise on a global basis. I am marking down the
severity of this to normal unless you can convince me that most of it is in
Netlib.
glynn, second request.  How does this look with latest build?
latest avail build, Jan 25, now crashes my win98 PC when I try this page, using
viewer.  Could be same cause, could be new cause.  Invalid page fault in module
RAPTORHTML.DLL.  On Mac, selecting about.html to start test run PPC mem
exception, crawl focusing on NS_NewNavHTMLDTD, On Linux it appears to be
hammering disk VM just trying to go to the page.
Severity: normal → major
Upped to major since this prevents running the grok test page.  Debug window on
Linux has popped out "handle_size_allocate: top level resize" when I tried to
ctrl D out, it is still hammering my hard disk, minutes later.
Severity: major → normal
So, the crashing is a new bug.  Just checked URL query and this one not written
against this URL yet.  glynn, please write a bug.  Thanks for checkin!
The crash may not be a new bug but a different path to the same bug here;
checking with gagan first and will file a new one if indeed it appears to be
different.
Setting all current Open/Normal to M4.
setting paulmac as QA contact for all gagan's bugs (sorry for the spam)
Feb22 Seamonkey, still unable to run grok page loader so cannot check to see if
recent checkins have fixed vm issue here.
Assignee: gagan → chofmann
Status: ASSIGNED → NEW
Cant see how this is Netlib only. Assiging to chofmann for assessment.
Target Milestone: M4 → M5
moving to m5
Assignee: chofmann → rickg
URL: http://grok/tests/page_loader → http://grok/tests/page_loader/about.html
Summary: Virtual memory suckage - trying to run grok page loader → browser buster still not running
there has been a lot of cleanup, but there still is work to be
doen to get browser buster working. there is a frame and
redraw problem currently
Status: NEW → ASSIGNED
Target Milestone: M5 → M6
The layout bug (seen at the top of this page as eyeballs that are left justified
instead of center justified) is caused by a <DIV align=center> that is outside
the <BODY> tag. We move and open the <DIV> but lose it's attributes.

The fact is, I already have the fix to this bug in my tree, but couldn't check
it in for M5 because the tree was so badly broken.
The layout bug (seen at the top of this page as eyeballs that are left justified
instead of center justified) is caused by a <DIV align=center> that is outside
the <BODY> tag. We move and open the <DIV> but lose it's attributes.

The fact is, I already have the fix to this bug in my tree, but couldn't check
it in for M5 because the tree was so badly broken.
paulmac, chofmann has Browser Buster running now.  Please checkout for a
Verification on this.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This is fixed now, I believe.
Status: RESOLVED → REOPENED
The layout problem with the eyeballs not center aligned still exists with 5/20
build. Here is the snippet, notice the misplaced DIV tag. Displays center
aligned in IE5 and 4.6. Re-opening bug.


<DIV ALIGN=CENTER>
<BODY>
Hello
</DIV>
</BODY>
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: FIXED → INVALID
I can't speak for browser buster, but the snipped given at the bottom of this
page results in a correctly formed content model. Rendering is wrong, in that
the text in the centered div is not centered. I'm closing this bug, and will
write a new bug for that.
Status: RESOLVED → VERIFIED
Marking Verified/Invalid
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.