139769 - Peoplesoft 8 page never completes loading

Status: RESOLVED WORKSFORME

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

Description

[Bob Babcock]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+)
Gecko/20020424
BuildID:    2002042403

Peoplesoft 8 is supposed to display a menu on the left hand side of the screen.
 With Mozilla, the page transfer never completes and this menu does not appear
unless I hit stop.  (It acts like it is continuously reloading, but I'm not sure
that is what is really happening.)  Netscape 6.22 and IE 6 work.  Netscape 4.79
works here but fails elsewhere.  Unfortunately, I can't give you a URL for this;
access to the page where I can test this is limited by router access lists and
passwords which I have no control over.


Reproducible: Always
Steps to Reproduce:
1. Log in to Peoplesoft 8
2.
3.

Comment 1

[Matthias Versen [:Matti]]

we can't do anything without a testcase...

(this is no blocker-> normal)

Comment 2

[hhwong]

Quick question -- is Mozilla sucking up memory while it's trying to display the
left-nav? I'm seeing it a little with 8.4, but it does display after a while,
but memory in Task Manager goes up about 1K/sec until I hit the stop button.
Very strange, because IE 5.5 doesn't seem to be going through this.

I'm using 2002061104 (1.1Alpha)

Comment 3

[hhwong]

OK -- I'm starting to narrow down a bit when this behavior starts.

Something changed between 0.9.8 (2002020406) and 0.9.9 (2002031104) that is
causing the problem. What's interesting though is that 0.9.9 does not have the
memory leak issue that 1.1 Alpha is having. What's *more* interesting is that in
playing the experimental build for trying to solve the bug 76831 that the memory
leak issue appears to go away, but I the constant reloading of the left-nav
still appears to be happening.

Unfortunately, since I can't build mozilla and the nightly builds only go back a
few weeks, I'm sorta stuck. But, if I find something else, I'll post...

Comment 4

[hhwong]

Attachment: Reloading child frame in frameset

Have a testcase here -- I hope. I changed all the refs to the PSFT app to
CNN.COM (I'm sure AOL TW will be happy about that).

Note that loading the nav_frame.html by itself is fine. But when you make it a
part of a frameset with testcase.html, it hoses up. 

And watch the memory usage on Mozilla sky... it eats up about ~1K/sec on Task
Manager.

Could this be related to bug 143398 ?

Let me know if this testcase works -- since I'm within the PSFT firewalls,
there may be some dependency here.

Comment 5

[hhwong]

Sorry for the spam. I forgot to mention which build -- 2002061707 on Win2K SP2
that I am observing this issue.

Comment 6

[Bob Babcock]

The test case submitted by hhwong fails for me with 1.1 alpha in the same manner
as the Peoplesoft page fails (continuous reloading, 100% cpu usage, memory leak).

Comment 7

[hhwong]

Attachment: Even Smaller Testcase

OK -- I managed to strip down the nav_frame.html file even more.

Looks like something in the BODY statement is causing the problem, which makes
me think that the onload= bugger is the problem. However, since I'm no
Javascript/HTML guru, I have no idea what this does.

Given that this causes recycling and shows a huge memory leak, should the
priority be bumped up?

Comment 8

[hhwong]

Still digging around (maybe I should actually get back to my real job :-)). The
only thing I can see from the check-ins between 0.9.8 and 0.9.9 that might have
something to do with this is the fix for bug 124427 ... maybe. Since I can't
build mozilla (and wouldn't know where to start), this is just speculation.

Note that in the test case for that bug, it doesn't stop loading, though it
doesn't have the same memory leak that I'm seeing with the above testcases for
this entry. Does the posted testcase here hit the onLoadHandler()? 

Given that this is showing a pretty big memory leak and will keep anyone from
using a mozilla-based browser for applications from a major ERP vendor, the
severity probably needs to be bumped up a notch. If Netscape wants to have any
usage in the enterprise, this probably needs to be fixed -- but maybe they don't
care about the enterprise as much....

Comment 9

[Bob Babcock]

At the suggestion of hhwong, and since we now have a simple test case, I kicked
the severity up one notch.  I hope this is ok.  This bug is a showstopper for us
as our parent organization moves to Peoplesoft.

Comment 10

[hhwong]

I hope this can be resolved sometime in the future. This testcase shows a *huge*
memory leak, which may be exposing some other problems. 

I know the Moz dev guys are pretty busy, so I promise not to bug them too much
again about this bug, but I do seriously think that this bug should bubble up.

Comment 11

[Andrew Hagen]

Confirming on Mozilla 1.1 alpha Build ID: 2002063008 Windows 98 on testing "Even
smaller Testcase." Affects a PeopleSoft app, so nsenterprise. Memory leak and
footprint issues. This is caused by a recent regression. 

Comment 12

[Matthias Versen [:Matti]]

-> Frames (?)

I really don't know who should get this.
I get this warnings before mozilla use 100% CPU :
WARNING: empty damage rect: update caller to avoid fcn call overhead, file d:/mo
z_source/gmake/mozilla/layout/html/base/src/nsFrame.cpp, line 2287

Comment 13

[Alfonso Martinez]

I would describe the problem this way:
1.) The onload handler of the frame sets
document.location.href='#EPCO_EPROCUREMENT' (in order to move the frame to a
specific tag), 
2.) This assignment forces a reload of the frame.
3.) As the frame is reloaded, we're back at point 1.

That's it: the navigation frame is continuously reloaded, so it doesn't matter
the content of the other frames, they can be set to about:blank.

So I think that the problem is just step 2.

Comment 14

[Kevin McCluskey (gone)]

nsbeta1+

Comment 15

[Kevin McCluskey (gone)]

Bulk moving P1-P5 un-milestoned bugs to future. 

Comment 16

[James Drabb]

I have encounterd this same problem with PeopleSoft Portal 8.4.  This
problem does not show up in IE, but appears in Moz 1.0.1, 1.1, 1.2b.  I
am implementing a Peoplesoft 8.4 protal now and came across this problem
with Moz.  I have collected some of the offending pages and javascript
and loaded them here: http://web.tampabay.rr.com/jdrabb/ps/
To test how the system works go: http://web.tampabay.rr.com/jdrabb/ps/ps.html
This will load ps.html which has two frames:
http://web.tampabay.rr.com/jdrabb/ps/scr1.html
http://web.tampabay.rr.com/jdrabb/ps/scr2.html

Mozilla seems to be stuck in some kind of a infinte loop, and processor
usage jumps up to 100% and stays there until I hit stop.
The page has about 140K worth of data between images, html and js
which can all be viewed here: http://web.tampabay.rr.com/jdrabb/ps/

James Drabb
-- 
---------------------------------------------------------------
Those who would sacrifice freedom for security will get neither
---------------------------------------------------------------
James Drabb JR
Programmer Analyst
Darden Restaurants
Business Systems
[e-mail]

Comment 17

[Andrew Schultz]

the second testcase worksforme with linux trunk 20030125 and 1.2.1, but does
fail with 1.1.  Does this bug still exist with recent builds?  Does there need
to be a new testcase?

Comment 18

[Andrew Hagen]

Both testcases are worksforme with (Mozilla 1.3 nightly) build 2003012304,
Windows 98. 

Can someone confirm that this problem still exists in the lastest Mozilla 1.3
nightly, as seen with Peoplesoft?

Comment 19

[Bob Babcock]

I just tested the 2003012804 build under Win/2K.  The bug seems to have been
fixed.  A quick test shows other parts of Peoplesoft working ok, which is
significant because Peoplesoft is a browser-challenging application.

Comment 20

[Andrew Hagen]

Thank you for reporting this bug, and for following up on it. Obviously, we
would want to fully support enterprise-level software like Peoplesoft. I'm glad
it's now working.

Resolving as worksforme. This appears to be fixed on trunk. 

If, in the future, this problem occurs again, this bug can be reopened. This bug
could also be reopened if there is a desire to see that this problem is resolved
on the 1.0.x branch, 

Comment 21

[nemo]

*** Bug 211400 has been marked as a duplicate of this bug. ***