Closed Bug 14916 Opened 25 years ago Closed 25 years ago

Cookie viewer gives javascript errors

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: morse, Assigned: pollmann)

Details

Attachments

(1 file)

working test case
661 bytes, text/html
Details 
Go visit some site that sets cookies and allow the cookies to be set.  Then go
to the cookie viewer (edit/wallet/display-cookies).  The cookies are displayed.

1. Select a cookie.  It's prooperties should be displayed on the right of the
window.  It isn't.

2. Press the delete key.  The entry should be removed from the list.  It isn't.
Instead we get the following error message on the console window:

   Javascript error: Uncaught Exception -- parameter is not a boolean
      file:
y:\mozilla\dist\win32_d.obj\bin\chrome\wallet\content\default\CookieViewer.js
line 68.

I'm not sure whom to assign this bug to, so I'm starting with Pollmann and I'm
sure he'll know whom to give it to.
Partly because of this bug, but more so because of crashing bug 14703, the
cookie viewer was scrapped and a completely new viewer checked in last night.
So this bug is currently not demonstrable.  In order to demonstrate it, fetch
the old cookie viewer from cvs and put it in your chrome directory.
Specifically fetch the following:

extensions/wallet/cookieviewer/CookieViewer.js revision 1.7
extensions/wallet/cookieviewer/CookieViewer.xul revision 1.6
extensions/wallet/cookieviewer/CookieViewer.properties revision 1.3

and then run the makefile in that subdirectory to get these files installed into
the chrome directory.  Once you've done that, you can follow the original
instructions for reproducing the bug as described in the bug report.

BTW, I should mention that this is a recent regression.  This was working as of
the beta freeze last Tuesday.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Sounds to me like there was an error in the old CookieViewer.js file.  Since
this is no longer demonstrable, and is certainly not a bug in forms or
framesets, I'm marking it invalid.  If it reappears, please reopen.
It obviously doesn't affect me anymore, but I think you are hidding your head in
the sand by marking it as invalid.  It is demonstrable (albeit somewhat harder
now that I've changed cookie viewers) by following the instructions that I've
indicated.  If it's not a forms or frameset issue, can you make a guess as to
what area it is and reassign it to that area?

I don't believe this is a bug in the old CookieViewer.js file because it was
working fine as of the the big freeze last Tuesday night.
While it is not my job to act as your bugzilla filter, I have already put a
guess as to what the bug may be in this bug report.  If you want me to analyze
it further, please attach a simple reproducable test cae.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Part 1 of this bug report is no longer a problem.  I just tried it out and it is
now working.

I did some further investigation on part 2 and it appears to be a compatibility
issue.  Specifically, the following statment is not an error in 4.x (nor was it
an error in versions of seamonkey prior to about September 21):

          selname.options[i-1].selected = 0;

In current seamonkey this gives the following js error message:

   Uncaught exception: parameter is not a boolean

Of course changing the 0 to false makes it work just fine.

For a simplified full test case demonstrating this, see below.


<html>
  <head>
    <script>

    function Deselect() {
      selname = top.frames[0].document.fSelectCookie.selname;
      var i;
      for (i=selname.options.length; i>0; i--) {
        if (selname.options[i-1].selected) {
          selname.options[i-1].selected = 0;
        }
      }
    }

    function loadFrames(){
      top.frames[0].document.open();
      top.frames[0].document.write(
        "<form name='fSelectCookie'>" +
            "<table>" +
              "<tr>" +
                "<td>" +
                      "<select name='selname' size='10' multiple='multiple'>"+
                        "<option>CookieA</option>" +
                        "<option>CookieB</option>" +
                      "</select>" +
                "</td>" +
              "</tr>" +
            "</table>" +
          "<input type='button' value='delete' onclick='top.Deselect();'>" +
        "</form>"
      );
      top.frames[0].document.close();
    }

    </script>
  </head>

  <frameset rows = "125,50" onload="loadFrames();">
    <frame src="about:blank">
    <frame src="about:blank">
  </frameset>

</html>
We get the same error message shortly before crashing at my.yahoo.com (bug
17345), if that helps.
Status: REOPENED → ASSIGNED
I think Vidur may have just fixed this recently, checking...
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
Yes, the "selected = 0" syntax no longer causes a javascript error.  I'm pretty
sure it was Vidur's fix.  Anyway, I'm attaching a simplified test case:
Attached file working test case — 

    
    

    
  
With this test case, you will see a list box with a button underneath it.  When
you select some items in the list box, then click on the button, all of the
selected items will be deselected.

I noticed another error in the original test case, but this is new and should
probably be a separate bug filed on the javascript security folks:
JavaScript Error: access disallowed from scripts at [Codebase
http://blueviper/forms/boolean.html] to documents at another domain
URL: http://blueviper/forms/boolean.html
LineNo: 17

JavaScript Error: uncaught exception: [Exception... "Security error"  code:
"1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)"  location:
"http://blueviper/forms/boolean.html Line: 17"]

    
    

    
  
This new bug is already reported and assigned to Norris, so please disregard it
and place any comments on bug 13192.  Thanks!

    
    

    
  
this was my fault, btw. I checked in a fix yesterday which nailed it :)

    
  
QA Contact: cpratt → tever

    
    

    
  
verified:
NT 2000020215
Status: RESOLVED → VERIFIED

    
    

    
  
Changing component to Browser-General. (HTML Dialogs is going away, and this bug 
doesn't look suitable for XP Apps on quick glance.)

Component: HTML Dialogs → Browser-General
Product: Browser → Seamonkey

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: