Closed Bug 18499 Opened 25 years ago Closed 25 years ago

[DOGFOOD] Ziff-Davis browser benchmark tests can't run (cookie prob?)

Categories

(Core :: Networking: Cookies, defect, P3)

Product:
Core
Component:
Networking: Cookies
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 18769

People

(Reporter: cpratt, Assigned: morse)

References

(
URL
)

Details

Attachments

(1 file)

A run button
1.53 KB, image/gif
Details 
Build ID: 1999111009
Platform: Windows NT

Does not crash using the 1999110908 build on Linux

To reproduce:
- Launch the browser
- Load the above URL
- Click the Run button

Result: You crash.

Expected result: You don't.

This bug will probably evolve into a metabug covering problems with Z-D's new
Internet browser benchmarking tests. I expect that they'll eventually be useful
for demoing the software when we get it running.

A Dr. Watson log for the NT crash is at http://schist/ibench-nov10.txt.
Assignee: leger → morse
Component: Browser-General → Cookies
QA Contact: leger → tever
Additionally, the 1999110908 builds (M11 builds) cannot run these tests due to
what appears to be a cookie problem - a dialog is displayed that says "a
required cookie is missing". Changing component to cookies in hopes of getting
an answer to that one...
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
I don't know about the cookie problem -- I am not getting that far due to the
crash.  And the stack trace that I get for the crash is identical to the stack
trace that is reported in bug 18493.  This is the third bug assigned to me today
that has that identical stack trace.  Looks like some major regression occured
yesterday that is causing all this.

Please file a separate report on the cookie problem if it ever comes back after
this crash is fixed.

*** This bug has been marked as a duplicate of 18493 ***
Status: RESOLVED → REOPENED
Summary: Ziff-Davis browser benchmark tests crash Mozilla → Ziff-Davis browser benchmark tests can't run (cookie prob?)
Reopening. If you use the 1999110908 builds on any platform, you don't crash
(and yes, the crash on the 1999111009 builds is a duplicate). You do however run
into a problem with cookies which prevents you from using the site well.
Resolution: DUPLICATE → ---
*** Bug 18493 has been marked as a duplicate of this bug. ***
Status: REOPENED → ASSIGNED
Target Milestone: M12
OK, I grabbed waterson's fix to 18493 and now am able to get to the cookie
problem.  Yes, I see the symptoms being reported.  I'll accept the bug.
Summary: Ziff-Davis browser benchmark tests can't run (cookie prob?) → [DOGFOOD] Ziff-Davis browser benchmark tests can't run (cookie prob?)
Well I spent a lot of time reducing this to a simple test case.  Having done so,
I'm now convinced this is not a cookie problem, although it did appear to be so
at first.  Now I need to figure out whom to reassign this to.

The test case is shown below.  It presents two links, one being textual and the
other being an image.  Clicking on the textual link works fine -- you get both
of the alert messages in the setSelectionPerf routine.  If you click on the
image, you get the first message but not the second.  Furthermore, you hit a
debug assertion as shown below (no such assertion for the textual link).

Here's the simplified test case.  Note it uses a gif file which I'll attach.
However there is nothing special about that gif file -- any old gif file will
demonstrate the same problem.

<html>
  <head>
    <script>
      var perfSingle = new Array(0, 1, 2, 3, 4, 5, 6, 7, 8);
      var testList = new Array();

      function setSelectionPerf() {
        testList.length = 0;
alert("get here");
        testList = testList.concat(perfSingle);
alert("don't get here");
        return false();
      }
    </script>
  </head>

  <body>
    <form name="perfTests">
      <a href="about:blank" onClick="return setSelectionPerf()">
        <img src="run.gif">
      </a>
      <a href="about:blank" onClick="return setSelectionPerf()">
        Run
      </a>
    </form>
  </body>
</html>

and here's the stack trace at the assertion failure:

NTDLL! 77f76274()
nsDebug::Assertion(const char * 0x004d7578, const char * 0x004d7564, const char
* 0x004d7538, int 463) line 284 + 13 bytes
nsJSContext::InitClasses(nsJSContext * const 0x023872d0) line 463 + 39 bytes
nsJSContext::InitContext(nsJSContext * const 0x023872d0, nsIScriptGlobalObject *
0x02384974) line 393 + 12 bytes
GlobalWindowImpl::SetNewDocument(GlobalWindowImpl * const 0x02384974,
nsIDOMDocument * 0x02a0b5e4) line 333
DocumentViewerImpl::Init(DocumentViewerImpl * const 0x02a0b400, void *
0x03ef036e, nsIDeviceContext * 0x0238fed0, nsIPref * 0x0106a930, const nsRect &
{...}, nsScrollPreference nsScrollPreference_kAuto) line 364
nsWebShell::Embed(nsWebShell * const 0x0238ca40, nsIContentViewer * 0x02a0b400,
const char * 0x029ce9b0, nsISupports * 0x00000000) line 907 + 69 bytes
nsDocumentBindInfo::OnStartRequest(nsDocumentBindInfo * const 0x029cb7d0,
nsIChannel * 0x029ce840, nsISupports * 0x00000000) line 1164 + 36 bytes
nsChannelListener::OnStartRequest(nsChannelListener * const 0x029cb750,
nsIChannel * 0x029ce840, nsISupports * 0x00000000) line 1352 + 43 bytes
nsInputStreamChannel::OnStartRequest(nsInputStreamChannel * const 0x029ce844,
nsIChannel * 0x029cf770, nsISupports * 0x00000000) line 289
nsOnStartRequestEvent::HandleEvent(nsOnStartRequestEvent * const 0x029dcef0)
line 246
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x029de9d0) line 173 + 12 bytes
PL_HandleEvent(PLEvent * 0x029de9d0) line 537 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x029173b0) line 498 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0ece0446, unsigned int 49375, unsigned int 0,
long 43086768) line 972 + 9 bytes
USER32! 77e71268()
029173b0()
Attached image A run button — 

    
    

    
  
And I forgot to mention, this works fine in 4.x.  Pressing either link will give
you both assert messages.

    
    

    
  
either the url or steps to reproduce aren't right. I have no idea how to
reproduce this. I tried making an html file out of steve's code but when I click
on the links nothing happens (I goto a blank page). (I'm using a pull from last
night). The stream listener is the docloader's which is normal. This is looking
like a js problem.

    
    

    
  
Forget the url.  Use my test case.  Yes, it's normal to get a blank page after
you press on the link.  The question is, how many alert messages did you get
prior to getting the blank page.  You are supposed to get two.  Clicking on the
textual link indeed gives the two alerts.  But the image link gives only one.

On 4.x, both links give the two alert messages.

    
    

    
  
I didn't get any? were they supposed to be dialogs?

    
    

    
  
Jud, the reason you didn't the the alerts is because alerts are broken in this
morning's build.  I just filed bug 18702 on it.

    
    

    
  
OK, with this mornings build everything has suddently changed with this bug.  I
replaced the broken "alerts" with "dumps" instead and surprisingly both dumps
appeared in both cases (text link and image link).  So it appeared as though
maybe this bug is now fixed.  So I tried the orginal url but it is still broken.

So now I'm back to square one, having once again to generate a simplified test
case so I can zero in on the problem.

    
    

    
  
No, I guess I'm not back to square one after all.  The work-around for the alert
bug, as mentioned in bug 18702, is to put the following line in prefs.js:

  user_pref("security.checkxpconnect", false);

With that line inserted, my simplified test again fails as I described above --
i.e., two alerts for the text link but only one for the image link.

    
    

    
  
Let's restart from the beginning.  All the symptoms have changed because of the
alert business.  In fact, I now realize that even before today's alert bug, just
having the alerts in the javascript was changing the behavior.

So here's a new simplified test case without any alerts.  Pressing the textual
link takes you to the correct page.  Pressing the image link gets you to the
wrong page.  And I don't know why yet.

<html>
  <head>
    <script>
      function X() {
        document.location =
"http://i-bench.zdnet.com/ibench/performance_tests/perf_loadcomplexpages.php";
        return false;
      }
    </script>
  </head>
  <body>
    <table>
      <form>
        <a href="http://i-bench.zdnet.com/ibench/testlist/home_js.php"
onClick="return X()">
          <img src=run.gif">
        </a>
        <a href="http://i-bench.zdnet.com/ibench/testlist/home_js.php"
onClick="return X()">
          Run
        </a>
      </form>
    </table>
  </body>
</html>

    
    

    
  
And I can make it still simpler as shown below.  No more fetching of files from
Ziff-Davis' site so we can now see all files that are involved.  If all three of
the following files are put on the local disk (along with the run.gif image),
you can actually observe something interesting -- when the image link is clicked
the correct page actually comes up briefly but is immediately replaced by the
wrong page.  When the text link is clicked, the correct page come up and
remains.

I think I've got all the clues, now I just need someone to look at it and tell
me what this all means.  Harish, pollmann, vidur -- do any of you have any
insights?

<html>
  <head>
    <script>
      function LoadPage() {
        document.location = "pass.htm";
        return false;
      }
    </script>
  </head>
  <body>
    <form>
      <a href="fail.htm" onClick="return LoadPage();">
        <img src=run.gif">
      </a>
      <a href="fail.htm" onClick="return LoadPage();">
        Run
      </a>
    </form>
  </body>
</html>

File pass.htm
-------------

PASSED

File fail.htm
-------------
FAILED

    
  
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE

    
    

    
  
This bug report contains too much historical information so as to make it
confusing to whomever I'm going to reassign it to.  So I've opened a new (clean)
bug report on it (bug ...) and am marking this as a dup of that one.

*** This bug has been marked as a duplicate of 18769 ***

    
  
Blocks: 18951

    
  
Status: RESOLVED → VERIFIED

    
    

    
  
Sounds good...marking Verified/Dup

    
  
No longer blocks: 18951

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: