Closed Bug 78188 Opened 24 years ago Closed 24 years ago

jrgm.mcom.com/page-loader/loader.pl unable to load spinner.com

Categories

(Core Graveyard :: Embedding: APIs, defect)

x86
Windows 98
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME
mozilla1.0.1

People

(Reporter: bmartin, Assigned: chak)

References

Details

latest mfcembed 04-27-01 O/S: Win98 System: HP Vectra VL 266MHz 128MB RAM Steps: 1. Download latest embed-win32.zip and extract it 2. launch mfcembed.exe 3. goto jrgm.mcom.com/page-loader/loader.pl 4. select submit Results: When script completes, www.spinner.com has NaN results for all five iterations of the page load. This has been the result for the past month for this URL. Going directly to http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/index.html appears to load fine
-> chak
Assignee: adamlock → chak
Running it via the .pl script or going directly to the URL (as mentioned above) loads the page correctly. However, the OnLoad() handler does not seem to get fired within the 30 second limit the script extects it in - hence the "NaN" in the final results table. I also noticed the following after the spinner page was loaded/displayed: 1. The progress bar does not completely get cleared even after the page is loaded. Placing printf statements in the nsIWebProgressListener callbacks showed that either i'm not interpreting the values passed in correctly or i'm being sent bogus values. I also noticed several callbacks with the same param values in succession. 2. The busy cursor (Arrow+HourGlass) is displayed well after the page is displayed. (The above behavior is just for the spinner page) I think these are all related. Cc:ing Rick and Adam for comments
*** Bug 78186 has been marked as a duplicate of this bug. ***
Targeting to 0.9.1
Target Milestone: --- → mozilla0.9.1
This bug is a little bit confusing. If you type "http://www.spinner.com/index.html" directly into the address bar, you get redirected to a different page than if you go via the perf URL. Is it possible that the perl script feeding out the content isn't responding correctly to the redirect events?
I think the perf perl script has all that content "replicated" on jrgm.mcom.com Here's something else i noticed: 0. Shutdown mfcembed if it's already running. Restart mfcembed 1. Go to http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/index.html and you should see the busy cursor. 2. Now go back to the same URL by selecting in the URL bar the page load will complete and you won't see the wait cursor forever like in step 1 I put some print statements in nsDocShell::OnStateChange() which look like: (Lines with START are for the "STATE_START" case) Set 1 (This is printed out for step 1 above) ----- *** START : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/index.html *** START : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_7009755_123456_aol .html?target=external&width=468&height=60 *** START : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_92000123_123456_ao l.html?target=_top&width=124&height=191 *** START : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_92000124_123456_ao l.html?target=_top&width=124&height=121 *** START : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_92000125_123456_ao l.html?target=_top&width=124&height=73 *** EndPageLoad : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_7009755_123456_aol .html?target=external&width=468&height=60 *** EndPageLoad : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_92000124_123456_ao l.html?target=_top&width=124&height=121 *** EndPageLoad : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_92000123_123456_ao l.html?target=_top&width=124&height=191 *** EndPageLoad : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_92000125_123456_ao l.html?target=_top&width=124&height=73 Set 2 (This is printed out for step 1 above) ----- *** START : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/index.html *** START : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_7009755_123456_aol .html?target=external&width=468&height=60 *** START : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_92000123_123456_ao l.html?target=_top&width=124&height=191 *** START : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_92000124_123456_ao l.html?target=_top&width=124&height=121 *** START : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_92000125_123456_ao l.html?target=_top&width=124&height=73 *** EndPageLoad : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_92000123_123456_ao l.html?target=_top&width=124&height=191 *** EndPageLoad : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_92000124_123456_ao l.html?target=_top&width=124&height=121 *** EndPageLoad : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_7009755_123456_aol .html?target=external&width=468&height=60 *** EndPageLoad : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/html_92000125_123456_ao l.html?target=_top&width=124&height=73 *** EndPageLoad : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/index.html Notice that in Set1 we never get an *** EndPageLoad : http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/index.html eventhough a corresponding START was called. While in Set2 we have matching START/EndPageLoads
Correction: In my previous posting "Set 2 (This is printed out for step 1 above)" should actually read "Set 2 (This is printed out for step 2 above)" -^-
->0.9.3 since i'm not sure i can get it done in time for 0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.3
I'd like to note that while it would be good to have this working for testing purposes, I think the larger point is not whether it can load that particular page (or twin failure 'www.zdnet.com_Gamespot.com'), but whether this is pointing to a specific defect in how the embedded app handles page loads. Brent: does this load in another embedded application?
->0.9.4
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.3 → mozilla0.9.4
It should be noted that this failure is reproducible in other embedded enviorments besides MFCEmbed.
Target Milestone: mozilla0.9.4 → mozilla1.0
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
It now works for me.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.