locked
Script error: 'length' is null or not an object

    Question

  •  

    Dear All,

     

    Situation: I have a document library in MOSS 2007 with two content types and I don't display the "New Folder" command on the New menu. I also still use Office 2003 client applications.

     

    Case 1: I open a document based on the default document content type in Word 2003. I can save the document without error message, I can take a look at the properties of the document, also no error. The properties box only show a combo box with the available content types. Strange item there is that a 'folder' is in the list.

     

    Case 2: I open a document based on the added custom document content type in Excel 2003. When I save the document a script error pops up: 'length' is null or not an object. The popup asks if I want to continue running scripts, I select the 'Yes' option. The document gets saved without any further problems. The same error pops up when trying to look at the properties of the document (in the Excel 2003 client application)

     

    Case 3: When I do the same as in case 2, only thing different is that I change the 'Display new folder' settings in the advanced settings of the document library to 'yes'. I don't get the script error. When looking at the properties there are only two options available in the 'content types' combo box, the 'folder' option disappeared.

     

    Now my question, how do I get rid of the script error without having to set the 'Display the New Folder' setting to 'Yes'?

     

    Kind Regards,

    Luc

    • Moved by Mike Walsh FIN Saturday, June 20, 2009 10:58 AM admin q (From:SharePoint - Enterprise Content Management)
    Wednesday, August 29, 2007 3:21 PM

All replies

  • Same problem
    Occurs only with office 2003.
    It begins after I applied KB939592 which solved my backup problem.
    Any ideas ?
    Friday, August 31, 2007 1:00 PM
  • Anyone from SharePoint Team here ?

    The error eccurs in _vti_bin/owssvr.dll at line 11659.

    Thank's

     

    Monday, September 03, 2007 8:56 AM
  • I also have the same issue which started after applying KB936867 which fixed our inheritance permissions issue, but caused this problem to appear.

     

    Tuesday, September 04, 2007 7:34 AM
  • I have the same issue, but I'm not sure if we applied KB936867 or not (my admin is no vacation).  But, I'm pretty sure that this has something to do with content types.

     

    Whenever I try to save a document directly into a library using a network place, I am prompted to define the content type and the list that I am provided is not the same as the content types defined for the document library.

     

     

    Wednesday, September 05, 2007 3:10 PM
  • We got the same problem here and have been taking a closer look. Some strange behaviour I must say...

     

    Scenario 1: Document Library with 'Display the New Folder' setting to 'Yes'; content types "Document" and "CAO" (custom)

     

    Property window shows no error and works fine

     

    Scenario 2: Same Document Library with 'Display the New Folder' setting to 'NO'; content types "Document" and "CAO" (custom)

    1. Property window shows with error
    2. Click 'Yes' to continue
    3. Fields of the content type are not shown, just the content type dropdown with the CAO content type selected
    4. I open up the drop down and the 'Folder' content type shows in the dropdown!! That's real strange as I do not even have it defined in the document library. It gets stranger...
    5. Select the folder content type and the fields of the CAO content type show in the property window. duh? It gets even stranger...
    6. Just filled in the fields and saved the word document... Guess what... I have a folder content type in my document library with the word icon and de fileds filled (I can see the values in the default view).... You would think it just saved it as a CAO content type... hold on...
    7. Select 'view properties' in the context menu....it's a folder ....
    8. Ok lets try another way... create new doc of content type CAO.. save...error shows...click yes to continue
    9. select folder and see the fields... select "CAO" content type...shows error again...click yes to continue
    10. fill in the fields and save the document
    11. SharePoint has saved it correctly

    Any of you guys have any kind of solution for this? Don't know if the KB has been installed on the server... I'll be able to check that out tomorrow... to be continued.

     

    Grtz

     

    Tuesday, September 11, 2007 2:13 PM
  • Really NO ideas ?

    I need a solution. 

     

    Tuesday, September 18, 2007 5:27 AM
  • Indeed, this needs to be solved. Quite some people have this problem... A lot of companies are not yet

    moving to Office 2007, which means that the integration with Office 2003 has to run without these kind of errors.

     

    Thanks in advance for looking into this...

     

    Kind Regards,

    Luc

    Tuesday, September 18, 2007 8:57 AM
  • We began experienceing the same issue after KB936867 on libraries where we had added the content type "Link to document".  By going into the library settings and deleting this content type the error stopped.

     

    James

    Friday, September 21, 2007 2:36 PM
  • It seems that error appears only on Document libraries with custom Content Types.

    Maybe anyone from Microsoft will read this post and find a solution.

     

    Tuesday, September 25, 2007 9:28 AM
  • I found a similar post in another SharePoint group:

    http://207.46.236.188/MSDN/ShowPost.aspx?PostID=2105089&SiteID=1

     

    There are a few workarounds suggested but those weren't very helpfull:

    1. Users continue to click yes on the error.  The changes to the documents should be saved, although you may lose out on some metadata.

    2. Upgrade to Office 2007.  We have determined that this issue does not exist in Office 2007.

    3. Temporarily remove your content types from your document libraries.

    4. Move your documents to new document libraries that do not use content types -- they could be moved back later.

     

    The post indicates however also that there's a fix on it's way...

    Tuesday, September 25, 2007 12:15 PM
  • We're having the same issue on one of our doc libs that I set up content types on.  I deleted them from Galleries>Site content types, and turned off allow content types in the lib settings, but we still get this error. 

     

    When I turn allow content types back on and view the settings, the content type that I deleted still shows up.

     

    I'd really like to be able to fix this without deleting the doc lib and starting over.  Any ideas?

     

    Thursday, September 27, 2007 8:39 PM
  • Any news please ???

    Thursday, October 04, 2007 9:44 AM
  • Hi, i'm having the same problem here, first ocurring after KB936867

    . Want to let you know that I've applied Office 2003 SP3, did not solve the issue.

     

    I've made an incident at Microsoft. Will let you know more when i've had a reaction from the Microsoft Support Team (Sharepoint queue is very long at the moment)

    Friday, October 05, 2007 9:42 AM
  • Have the same problem, but not for all users, only some of them are having the bug.

     

    1) Open a document from a doc library which have a custom content type

     

    2) Edit it and click File - Close

     

    3) Word ask to save, click yes

     

    4) Sript error appears, click No every time

     

    5) Changes are saved but my content type is now a Folder. (wow)

     

     

    Thursday, October 11, 2007 12:28 PM
  • After applying hotfix KB936867 we also started having this error only on Libraries that have more than the default Content Type.  For us, if I remove ALL CONTENT TYPES excluding the default "Documents" one of course, AND I turn Manage Multiple Content Types to NO, AND force Check In/Out (all three of these) then our error goes away. 

     

    If you perform all 3 steps above it will temporarily remove the error. Removing Content Types does NOT remove those columns, it just changes them to custom columns.  I too have a call into Microsoft Support to push for a real fix, as we have many sites that rely quite heavily on Content Types.

    Linda

    Migration Specialists Inc.

    Friday, October 12, 2007 12:46 AM
  •  

    After applying hotfix KB936867 we also started having this error only on Libraries that have more than the default Content Type.  For us, if I remove ALL CONTENT TYPES excluding the default "Documents" one of course, AND I turn Manage Multiple Content Types to NO, AND force Check In/Out (all three of these) then our error goes away. 

     

    If you perform all 3 steps above it will temporarily remove the error. Removing Content Types does NOT remove those columns, it just changes them to custom columns.  I too have a call into Microsoft Support to push for a real fix, as we have many sites that rely quite heavily on Content Types.


    Linda - MigrationSpecialists.com

    Friday, October 12, 2007 12:51 AM
  •  

    Oddly enough, we started to get this error today as well, but in our case it is even more confusing:

     

    • Running MOSS 2007 Enterprise
    • Hotfix 936867 has NOT been installed
    • We are using Office 2007 products

    The document library has 2 content types enabled, both set to visable, and folders are turned off. What a PITA!

     

    Friday, October 12, 2007 9:21 PM
  • I am also having this same exact issue after some updates were automatically installed a few days ago.  However, I do not see the 936867 update in my Add/Remove programs list....

    I'll keep this thead up to date if I hear anything.
    Friday, October 12, 2007 9:44 PM
  • I have the same issue, and have not put in KB936867. It seems to have arisen after adding a custom column to a site with multiple content types. Even after backing out the changes and deleting the column, the problem remains. Has anyone had any feedback from Microsoft as yet?

    Wednesday, October 17, 2007 3:38 AM
  •  

    Any luck folks? I'm stumped and this is really turning into a huge issue for us as we just migrated all of our documents into SharePoint sites - and now people can't save new documents to some of them.

    Wednesday, October 24, 2007 3:54 PM
  • The only work around I know is to remove Custom Content Types (All of them). For us it was no a big deal since we did not really need them but it may be a problem for some of you to remove Custom content types. But the good news is that I got rid of the bug right after I removed them!!!!!

     

    Wednesday, October 24, 2007 6:22 PM
  •  

    Hi,

    How can I remove the custom content types if they are in use (documents properties hold them still). I tried adding another content type and move all the documents to that content type (so I can delete the custom content types) but with no success. Any suggestions? Did anyone hear something new from Microsoft?

    Sunday, October 28, 2007 10:03 AM
  • Our problems also came after appying that hotfix that we were instructed by AVEPOINT to apply to fix a backup problem of theirs (which it didn't fix either).  Remember this hotfix does not necessarily show up in your list of applied hotfixes.

     

    I placed a call to Microsoft Support for my customer stating this script error and 3 other functions that broke (loca breadcrumbs, dis-continue inheritance of permissions, not commenting on a blog after created from a saved template), they said "...the Development Group said those are known bugs/problems associated with applying that hotfix, and they have NO fix or workaround to provide currently...".  I pushed for a date and the best I could get was end of December to February possibly.

     

    For my customers I am able to get rid of their Content Type Script Errors by:

    1. Go to the Document Library turn ON Management of Content Types
    2. Then go through and remove every content type other than Documents. Some like Link to Documents, will say it is Read Only, that is okay, just go to Advanced Properties in that same window and change it to NOT READ ONLY, then delete that content type.  If you find content types that are in use, you can proceed and 90% of the time the next steps will still remove the script error.
    3. After removing all the content types that are not in use, then turn Management of Content Types back OFF.
    4. Turn force Check In/Out ON.

    Refresh and you will no longer have the script error.  Remember it will only suppress the error if you perform ALL steps above, not skipping any.  Most customers are not forcing Check In/Out #4 and still getting the error, or they skip step #3...you must perform all 4 steps.

    • Proposed as answer by Barkolounger2 Friday, January 08, 2010 3:43 AM
    Sunday, October 28, 2007 9:48 PM
  • Hi Linda,
    Thanks for the work-arround. We are facing the same problem with WSS 3.0 having plced several content-types on a document library. Your solution works, but we loose the multi-content type feature. Am I wrong or is that what your work-arround comes with?
    Benjamin.
    Friday, November 09, 2007 3:49 PM
  • Benjamin:

    When you perform those above steps, you will not loose any functionality but being able to post new items as different content types.  This is a temporary workaround until Microsoft provides a fix and you have to look at it as such.  I have been on my 3rd call with Microsoft Support for a week now.  I do not think enough people are actually calling Microsoft Support and formally reporting the problem. If they cannot fix your problem they will refund your Support Call, so you are not loosing anything by calling.

    Friday, November 09, 2007 4:07 PM

  • Also have this problem after applying the hotix to resolve :

    935958 (http://support.microsoft.com/kb/935958/) Error message when you try to connect to a site in a Windows SharePoint Services 3.0 site collection after you configure a document library to inherit permissions: "HTTP 500 - Internal server error"

    whats the best way of reporting it
    Wednesday, November 14, 2007 4:51 PM
  • Linda,

     

    I have just checked the details of this issue and it is something that Microsoft is aware of as an urgent issue and something that is being actively worked on.

     

    Kind Regards

    Chris 

     

    Saturday, November 17, 2007 2:45 PM
  • That's good news. Let's hope for a quick solution!

     

    Monday, November 19, 2007 9:19 AM
  • In a library, when I add a new document by clicking 'New' > specific content type, Word opens, I change the document, click Save. A dialog opens for the name of the document and after that the properties dialog opens to specify the metadata for that document. Only the content type drop down box is shown while there are other columns attached to this content type. Off course I also get the script error when I switch from one contenttype to another. Is it possible that these issues are related?

     

    Kind Regards,

    Luc

     

    Thursday, November 29, 2007 2:41 PM
  • I am experiencing exactly the same problem and it is hard to believe that Microsoft has not come up with a solution yet, especially since the problem has been reported for the first time in August!

     

    Just a recap of the issue:

     

    The problem occurs when using multiple content types in combination with Office 2003 and it basically makes the multiple content types feature in combination with Office 2003 unusable:

    • When using multiple content types on a Library in SharePoint and when using Office 2003, a Javascript error pops up when trying to save a document from Office back into the library
    • The error prevents saving the document back to a specified content type when creating a new document (and will thus prevent the correct metadata to be saved with the document), regardless of whether the document is created from within Office and saved into the library directly, or wether it is started by click the "New…" button in the library
    • When opening an existing document from a library with multiple content types and saving it, the same error window pops up 4 times before the document is saved
    • The same error pops up when modifying the document properties from within an Office 2003 document

    Also reported on the MSDN forum: http://207.46.236.188/MSDN/ShowPost.aspx?PostID=2105089&SiteID=1

     

    Microsoft support, please post a reply to give us an update on the status of this issue!

     

    Thanks,

    Jeroen

     

    Tuesday, December 11, 2007 4:47 PM
  • Dear all,

     

    More info in following post: http://njbblog.blogspot.com/2007/12/sharepoint-v3-error-ie-script-error.html

     

    Kind Regards,

    Luc

    Wednesday, December 12, 2007 10:15 AM
  • Sorry but there was nothing new posted there.  Microsoft Support has already confirmed this to be a bug as a direct result of applying a HotFix KB939592.  They confirmed this as a bug as early as end of August right after these started popping up. Some libraries and custom web parts, workflows etc completely rely on Content Types...so none of those options are real workarounds. Microsoft has given us NO WORKAROUNDS...it was the user community that figured out those so called "workarounds" not Microsoft.  I think this is unacceptable that we go for 5 months now without a fix.

    Wednesday, December 12, 2007 4:18 PM
  •  

    Has anyone tested this issue with the WSS 3.0 SP1 which was released yesterday?

     

    Thursday, December 13, 2007 2:50 PM
  • OK, SP1 has fixed the problem! Strangely enough it is not in the release notes for MOSS or WSS3 SP1 but after installing these in our DEV environment the problem no longer occurs.

     

    The release notes do mention an update to owssvr.dll (which seemed to be the component with the broken script) but not related to this specific problem. Anyway, it's fixed for us, thank you Microsoft SharePoint team!

     

    Jeroen

     

    Thursday, December 13, 2007 4:50 PM
  • Are you sure it fixed all the issues with Content Types, that script error was just the most "visable" problem.  We have an open Support Ticket with Microsoft and talked with the development team and they were very clear to us just two weeks ago that they did NOT have time to incorporate a fix for this problem into SP1 and that they would not even have time and resources to work on a fix for this until AFTER SP1 was released.  So now they are working on it.  Us applying that hotfix that broke items actually broke 4 items for our customers not just Content Types.  So you might want to look at the other broken items I list in the above threads and test those to see if they are also broken for you too.

    Thursday, December 13, 2007 5:44 PM
  • the Content Types problem seems to have been the biggest issue for most people in this thread and for us this feature is working again with Office 2003 after installation of SP1.

     

    can you please clarify the other issues that you ran into? your post mentioned: "loca breadcrumbs, dis-continue inheritance of permissions, not commenting on a blog after created from a saved template", can you give some more detail?

     

    thanks,

    Jeroen

     

    Thursday, December 13, 2007 6:01 PM
  • We didn't notice these at first, but later we realized other items had broke, and we were able to reproduce all of these for Microsoft Support as a direct result of applying that HotFix.

     

    In addition to content types

    1. local breadcrumbs - on only our sites that had SUB-SITES, if we had dis-continued inheritance of permissions, then tried to re-inherit, it broke the local breadcrumbs of the sub-site only, you get a page not found error.  If you manually added default.aspx to those sub-site urls after the error then it resolved once. 
    2. dis-continue inheritance of permissions - in the same above example...we cannot discontinue inheritance of permissions on sub-sites anymore...at all. It works for Top Level Sites and their direct sites but not sub-sites. 
    3. not commenting on a blog after created from a saved template - If you create any blog site, and COMMENT on a post it works.  But then if you save it up to the gallery as a new Blog Template, all Blogs sites you create from that template the COMMENT  feature on a Blog does not work.  Not even Farm Administrators can comment on a blog.  If you save that template off as we did and sent it to Microsoft they couldn't Comment either. - This one was HUGE for us because we have over 20 cosmetic changes we make to the blog, so we needed a template so as to not have to manually change every blog.

    Microsoft confirmed for us all 3 as additional bugs due to the hotfix, and to not expect a fix until after SP1 was released. 

    Thursday, December 13, 2007 6:21 PM
  • Interesting, I can not reproduce your first two issues (which seem to be related anyway), neither on our PRD environment without SP1, nor on our DEV environment with SP1. On both environments I can break and re-inherit permissions on sub-sub-sites and breadcrumbs keep working.

     

    However, I do have the same problem with the Blog comments on a Blog created from a custom template, even on our SP1 DEV environment.

     

    The thing is: I am not sure if KB936867 has been installed in our environments; I don't see it listed anywhere and the environments were already in place before I started here (as a consultant). So that makes me wonder if some of these issues are even related to this hotfix or if they were introduced by some other patch...

     

    Good luck getting it resolved!

    Jeroen

     

    PS. You might want to start a new thread for these remaining issues since the title of this thread refers to the Content Type problem only.

    Thursday, December 13, 2007 6:41 PM
  • SP1 has been installed, the server restarted, but I still get the 'lenth is null or not an object' error. I have not taken the drastic step of unwidning all of the changes to implement document types, as these are ingrained.

    Anyone have any further ideas? If you have managed to implement SP1 and successfully avoid these errors, was there anything else you had to do?

    Monday, December 17, 2007 1:06 AM
  • we installed both WSS3 SP1 and after that MOSS SP1. we didn't make any further changes but the Content Type problem went away and we no longer get the script error in Office 2003 when connecting to a library with multiple content types.

     

    sorry, no further ideas...

     

    jeroen

     

    Monday, December 17, 2007 1:16 AM
  • We also have SP1 installed and are still getting the errors. I had really hoped this would fix this problem as I have a very unhappy client right now. The content type feature is a great benefit to them and I haven't removed them as it will change the way they work. Certainly there has to be a fix for this!

    Wednesday, December 26, 2007 7:12 PM
  • We have installed SP1 too. We are still getting the problems with WSS 3.0 an Office 2003. Is anybody out there who has installed the SP1 and has solved the problem with it?

    Thanks in advance, Theo
    Wednesday, January 09, 2008 9:45 AM
  • I have just installed WSS3 SP1 and I'm still getting the same error. This is beyond agravating, halting the system from moving to a production environment. Microsoft, what's the deal?

     

    Wednesday, January 09, 2008 6:53 PM
  •  

    We were able to resolve the 'length' is null or not an object issue associated with content types in MOSS 2007 and Office 2003 client software by installing SP1 for WSS and MOSS.  Installing SP1 alone did not resolve the issue.  It was also necessary to rebuild the end user user profiles on their desktop computer.  (Renaming the user profile directory in XP and having the user login to the desktop system fixed the issue.  Shortcuts and application data may then be migrated from the old profile to the new profile.  After confirming the profile flush fixes the issue.)
    Friday, January 18, 2008 7:47 PM
  • Anyone new entering this thread should take the time to read all replys entered above.  SP1 is not suppose to fix any of these issues.  We have an open ticket with Microsoft and they said they did not have time to work on this fix until AFTER SP1 was released. So we are to expect a fix in Q1 of 2008.  For those people that SP1 fixed their problem...that is just by chance with their configuration because Microsoft did not add a fix into SP1 for this...they confirmed that.  Also I caution you that this content error is only one of the most apparent most visible bugs caused by this hotfix.  So just because you don't see that error anymore don't assume all underlying bugs are fixed.

    Thursday, January 24, 2008 12:28 AM
  • Is there a KB number for this problem, so we can follow the updates on this problem?

     

    Like most of the people in this thread, our organisation also has alot of benefit with the coming fix.

    Also we hope that it will arive in Q1, well at least as soon as possible Smile.

     

    Thanks for the info Linda.

    Friday, February 01, 2008 10:18 AM
  •  

    Is anyone else finding that this effects there permissions (having read this forum, i can't see another comment about it). But if i go in as a TestUser with read permissions i can view the file. When i click save, the error displays. After continually pressing yes you can then can eventually save the document.

     

    Im pretty sure my permissions are correct.

    Tuesday, February 05, 2008 3:48 PM
  •  

    The lack of a timely response to this issue by Microsoft is infuriating.  I am in the middle of developing my first MOSS site and have been extolling the virtues of content types to everyone I've talked to about it.  I never noticed it before on my development machine at home because I have Office 2007 installed.  Didn't notice it until late last week - and I've got a big presentation about the wonders of our new MOSS site next week.  Glad I found this out beforehand. 

     

    I think I've found a decent workaround - at least for situations like mine where we haven't taken it live yet.  The crux of it is to create separate document libraries for each "would-be" content type, adding the appropriate site columns and document template, then use a Site Aggregator webpart to make it easy to navigate to the individual document libraries.  Not optimal, but it'll do until the gods (they currently warrant a lower-case g) have a fix.

     

    C'mon Microsoft - the least you can do is post an update to this forum!

     

    Woof!

     

    Saturday, February 09, 2008 11:26 PM
  • Hey all,

     

    Does anyone have a status update for the script error: 'length' is null or not an object?

    I learned that it is caused by using custom content types in a document library.

     

    I hope it can be fixed soon.

     

    Monday, February 11, 2008 2:47 PM
  • This bug has been reported to Microsoft since August 2007. Remember guys/gals...this bug is with Content Types, which are used in almost everything...not just libraries.  So just the most apparent visible error is "noticable" in Document Libraries...but all lists, workflows, etc also use Content Types and are therefore also possibly affected in different ways.

     

    Microsoft just called us this week and said they HOPE to release a fix for this bug by the first week in March maybe last week of February.  I will post as soon as they do. 

    Monday, February 11, 2008 3:53 PM
  •  

    Guess my content type problem is related to this. This is the nearest I've found to it in a week of searching! I too am using MOSS 2007 with multiple content types and Office 2003.

     

    Have set up several document libraries each with several content types and have supressed the 'new folder' option. When a user selects a specific content type the dialogue requiring entry of metadata is wrong - it displays the next content type meta data not the one selected. Not really acceptable!

     

    If I modify the document library to enable the 'new folder' option the problem disappears. Doesn't anybody else have this problem?

     

    It looks like a symptom of a MS mistake in array handling on multiple content types, not adjusting for the absence of 'new folder' in the content type list, so perhaps similar cause to the symptoms you guys are experiencing.

     

    Thanks all for pursuing this problem - hope it should get resolved soon and also sort out my problem.

     

     

    Wednesday, February 20, 2008 11:14 AM
  • We installed SP1 and now we are experiencing the issue. Never had it before and now it is happening on teh Production server, the QA box was never affected.

     

    I have tried limiting the content types to teh default document on a Document Library and I still receive the pop up javascript message.

     

    Anyone get help from Microsoft or figure out a work around?

     

    On the phone with Microsoft

    Hot fix for this issue is projected to be available in April but that is not guaranteed. Could be pushed further back it depends on the complexity of the fix.

     

    Option is to upgrade to Office 2007 or rollback to a pre SP1 from a backup.

     

    Wednesday, February 27, 2008 4:15 PM
  • Hi Everyone,


    I have been confronted with the error for some time as wel.

    I started digging through the script files that are included in the office 2003 popup dialog HTML which is outputted by the owssvr.dll.

    I now know where the error originates in bform.js located C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\(1033)

     

     I fixed the error message so users can now select the right content type and save the document without errors (Meta data fields are hidden at the moment).

    We needed this fix realy bad so i rolled it out after i found this solution.

    No i am working on the script file so that the meta data is also shown.

    I will post an update as soon as i finish.

    Make sure u check out my awsome fishing website www.roven.nl Smile !!

     

    I'll give you the details on the fix here:

     

    On row 10326 replace this method

    Code Snippet

    function ChoiceFieldFocus()
    {
    try
    {
     if (this.rgChoices.length==0)
      return false;
     var bSelectedFillInChoice=false;
     if (this.fFillInChoice)
     {
      if (this.format=="RadioButtons" || this.format=="Checkboxes")
      {
       var fieldControl=this.frm.FieldSubPart(this, this.format);
       for (i in this.rgChoices)
       {
        if (fieldControl[i].checked)
         break;
       }
       if (i==(this.rgChoices.length-1))
        bSelectedFillInChoice=true;
      }
      else
      {
       var fillInButton=this.GetFillInButtonControl();
       if (fillInButton.checked)
        bSelectedFillInChoice=true;
      }
     }
     if (bSelectedFillInChoice)
      var field=this.GetFillInControl();
     else
      var field=this.GetControl();
     if (!field.disabled)
     {
      field.focus();
      return true;
     }
     return false; 
    }
    catch(err)
    {
    }
    }


    On row 11659 replace this method

    function Belong(elem, rg)
    {
    try
    {
     var i;
     for (i=0; i < rg.length; i++)
     {
      if (elem.stName==rg[i].stName)
       return true;
     }
     return false;
    }
    catch(err)

     return false;
    }

    }

     

     

     

    Thursday, February 28, 2008 11:27 AM
  •  

    Nice Workaround! Wouldn't go as far as calling it a solution, but try-catching the body of both functions is a nice way to keep the end-users happy.

    Thanks for looking into it.

     

    Does anybody know if this problem is solved in the post SP1 rollup package?

    WSS: http://support.microsoft.com/kb/941422

    MOSS: http://support.microsoft.com/kb/941274

     

    Anyone from Microsoft with a fix? You now know where the problem resides... .

     

    On what version of SharePoint did you fix the code? With or without SP1?

    Thursday, February 28, 2008 12:57 PM
  • With SP1, but the error was already there before the SP.

    Thursday, February 28, 2008 3:36 PM
  • Microsoft called me just last week and they said they now will NOT have a fix at the end of February like they hoped, and they also did not have an estimate on when they will.  They have confirmed that this bug was NOT fixed with SP1 or any other releases yet...they are still working on a fix.

     

    Also there is no real solution or temporary fix...the bug with Content Types goes deeper than just that surface Script Error.  Again I say...that more people that have Premier Support need to be opening tickets complaining about this bug...or they simply are not going to be under enough pressure to fix this!

    Thursday, February 28, 2008 4:10 PM
  •  

    Hey MS, pay some attention. Here is your fix!

    I was so desperate that i forced myself to fix this, i did not want to wait for a MS fix anymore.

    The problem comes from one missing line in the method of the file bform.js located in

    C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\(1033)

    Code Snippet

    SwitchControls(ctSelect, fSetDefault, fSetFocus)
    {
      frmCurrent.rgcts= _g_tp_rgcts;

     

     

    The area's where the metadata options are grouped together are stored in an array called _g_tp_rgcts

    But frmCurrent.rgcts is used to read those values. A transfer however, never takes place.

    So i copy the value into frmCurrent.rgcts first. I could replace it all in the code but i do not want to mess around with it to much.

     

    Also the BoolFromString2 method is called in the html of the dialog but does not exist.

    So add the folowing method to bform.js as well.

    Code Snippet

    function BoolFromString2(str,bool)
    {
     if (str=="true" || str=="TRUE")
      return true;
     return bool;
    }

     

     

    Hope you all will get some more sleep now.

    Well, now im going fishing! CU later.

    www.roven.nl

     

     

    Thursday, February 28, 2008 5:03 PM
  • Hey Bas (<dutch>Goed bezig!! </dutch>),

     

    The BoolFromSting2 function was the one that triggered me to ask on what version you've fixed the problem.

    We have a DEV/TEST environment where the BoolFromSting2 function exists and a PRODuction environment where it doesn't. I think the problem might be caused by the way the updates for SharePoint have to be installed. (First WSS, then MOSS, then languagepack)

    On the DEV/TEST environment the BoolFromString2 function looks like this:

     

    Code Snippet
    function BoolFromString2(str, def)
    {
     if (str==null || str=="")
      return def;
     if (str=="true" || str=="TRUE")
      return true;
     return false;
    }
    function BoolFromString(str)
    {
     return BoolFromString2(str, false);
    }

     

     

     

    On the PROD environment the function wasn't in the code. The way SP1 is installed on the servers differs (when SP1 was released, the upgrade procedure was not available). On the DEV environment we installed the MOSS SP1, the language pack SP1 and finally (after learning the procedure) the WSS update. It looks that we don't have the JavaScript error on that environment. Very strange.

     

    Now lets all hope Microsoft fixes the problem causing the JavaScript error. 

     

    Update: Adding the code (frmCurrent.rgcts= _g_tp_rgcts;) to 1033\BFORM.JS doesn't fix the problem for me.

    Update2: IT WORKS! The Script error is gone! Was testing it with a dutch version of office2003. So it makes sense I should fix the 1043\BFORM.JS

    Friday, February 29, 2008 6:41 AM
  •  

    Ok, let me tell some more.

    First of all my situation was WSS 3.0, no MOSS and ofcourse Office 2003 and 1200 whining users Smile. The error occured sometimes,  not always.

    Then i installed wss SP1 and after that the Dutch Langugage Pack SP and the errors occured always.

    (line 11659 length is not an object ).

    What you should look at is wat happens in you file /_vti_bin/owssvr.dll?location=Documenten/test bas.xls&dialogview=SaveForm (set the location to one that is valid for you). Just open this in a new window and view the source.

    This file contains a large javascript section where the page is created.

    What basically happens is that an array _g_tp_rgcts  is created to store all the sections of metadata fields per content type you select.

     

    Code Snippet

    // Array for storing all the sections

    var _g_tp_rgcts = new Array;

    // Array that stores the controls for one content type section

    _tp_rgctfld = new Array;

    // Control is created

    _tp_ctfld = new Object(null);
    _tp_ctfld.stName="ContentType";

    // Control is stored in the control array
    _tp_rgctfld.push(_tp_ctfld);

    // Control array is stored in the section array

    _g_tp_rgcts.push(_tp_rgctfld);

     

     

    Now when you make a choice in the dropdownlist of content typs, the switchcontrols method is called. This method then shows and hides the appropriate sections for you.
    IMPORTANT: Make sure that your _vti_bin/owssvr.dll generates _g_tp_rgcts to store the sections in. If this name is different, use that name in the first line of SwitchControls and not _g_tp_rgcts.

    Hope this works for you.

    One other thing, check which BFORM.JS is included, the folder 1033 or 1043 are just samples here. The depend on the language you have defined on your sharepoint website.

    Friday, February 29, 2008 9:51 AM
  • We experienced this same script error following application of SP1.  After a day or so of troubleshooting we identified the problem was with the bform.js file which is cached to the client and is not recached following SP1 update, which does update this file.  The error is caused because the clients are using the pre-sp1 version of the file cached to the client and not the version of the file updated in the service pack.

     

    We cleared the IE cache on the clients and that resolved the problem.

    Saturday, March 29, 2008 8:55 PM
  •  

    "We cleared the IE cache on the clients and that resolved the problem."

    What problem did this cure and in what circumstances? I have searched a client machine and found no sign of this file being cached, but still experience the script error problem when trying to save a document to a Sharepoint folder with custom meta-data fields enabled.

    Sunday, March 30, 2008 8:53 PM
  • We had no problems pre-sp1 update.  Following sp1 update when a file was edited through an office client a 'length' is null or not an object script error was thrown in the client (this was with a custom content type).

     

    Following a lot of troubleshooting with the server we cleared all the caches off the server and a test client and that appeared to have solved the problem for us but only with the test client.  It should be noted that our configuration did have caching profiles enabled.

    Monday, March 31, 2008 7:33 AM


  • Theres now a post SP1 hotfix for this ?


    http://kbalertz.com/950292/Description-SharePoint-Server-hotfix-March.aspx#top
    Monday, March 31, 2008 2:26 PM
  • We applied this and it did NOT fix our breadcrumb issue.

    Monday, March 31, 2008 2:34 PM
  • Microsoft sent us a posted fix for the Content Type error from our open ticket on Friday.  Here ii is:

     

     http://support.microsoft.com/default.aspx?scid=kb;EN-US;950292

     

    I am testing it now.

    Monday, March 31, 2008 3:06 PM
  • Hi Linda,

    Did the fix work for you? I too am experiencing the issue with content type/office 2003 javascript error. Please let me know.

    On a side note, does anybody know how I can hide the content type drop down list from web file properties box?

    Thanks,
    Emon
    Wednesday, April 02, 2008 5:16 PM
  • Does anybody know if I need to install SP1 before I apply the fix for the javascript error (KB950292)? For the fix the KB says it needs KB941653 applied which is post-SP1 hot fix. Please let me know.

    Does anybody know what would be the version # of SharePoint if SP1 is already applied?

    Thanks.


    Wednesday, April 02, 2008 7:58 PM
  • I was told by MS that you need WSS 3.0 or MOSS 2007  Service Pack 1  and the post SP1 Hotfix KB 941653  both installed as a Pre-requisite to installing this.  I don't know why they didn't list them under Pre-requisite, duh...

     

    You can see whether SP1 is installed by going to the server's Control Panel - Add/Remove Programs - Show Updates in the top corner - then it will list SP1.

    Wednesday, April 02, 2008 8:29 PM
  • Do you have to be premium member to download the hotfix? I cant seem to locate the download link anywhere on the page or am I just going crazy? Stick out tongue.

    Can you confirm if the version # SharePoint with SP1 is 12.0.0.6219?

    Thanks for your help.


    Wednesday, April 02, 2008 8:35 PM
  • Bas,

    Thank you so much for the fix. It works like a charm.

    Emon
    Thursday, April 03, 2008 2:41 PM
  • In my case the problem started appearing after installing MOSS SP1. I have applied the 950292 hotfix (along with the 941653 as the prerequisite), cleared IE Cache, but the problem is still appearing... Does anybody know a sollution to this?

    Urszula

    Wednesday, April 09, 2008 11:55 AM
  • Hi,

    I can confirm that the following process fixes this issue for me.

    1. install WSS 3.0 SP1 - en_windows_sharepoint_services_3.0_service_pack_1_x86.exe

    2. run wizard

    3. install MOSS 2007 SP1 - en_office_2007_servers_service_pack_1_x86.exe

    4.
    run wizard

    5. install hotfix KB 941653 - wss-kb941653-fullfile-x86-en-us.exe

    6. run wizard

    7. install hotfix KB 950292 - office-kb950292-fullfile-x86-glb.exe

    8. run wizard

    9. 'delete all browsing history' in IE 7 (check the "also delete files and settings stored by add-ons").

    10. test again - you should find that it is fixed then.

    Cheers!

    Tod.
    Thursday, April 10, 2008 4:27 AM
  • Tod, thank you very much for the information Smile

    That's also what i did, the only difference is that I'm using IE 6 instead of IE 7. Maybe it has something to do with that... I cleared all temporary internet files, offline content and history. Has any one with IE 6 successfully installed those 2 hotfixes?

     

    Urszula

     

    Thursday, April 10, 2008 11:41 AM
  • OK - Here is some more info.

    I have now deployed and tested this on three machines (localdev, dev and test) and it works in all three places...

    And yes - it works for me in IE 6.

    I'm not sure what patch level these PCs / servers are at (i.e. general windows patches), however I have noticed that with SharePoint you generally need to make sure that your IE 6 is the most up to date version - as you get some activex issues if you don't.

    My advice would be to clear all your caches again - and reboot your machine...

    Otherwise you could try a PC/VM that has NEVER user sharepoint before - make sure that PC/VM is on all the latest windows XP and office 2003 patches.

    I sincerely hope you get this one fixed... It is surely the most annoying bug I have ever experienced in SharePoint.

    Tod.
    Friday, April 11, 2008 12:08 AM
  • Yeah, seeing error message 5 times when saving a document is really annoying :/

    I'll install all the latest updates for my VM (i'm a little behindWink ) and let you know what happen Smile Thanks!!

     

    Urszula

     

    Sunday, April 13, 2008 8:04 PM
  • Installing all the updates didn't help :/. Of course i cleared all IE cache again and restared the system.

    Next step will be, like you said, testing from another VM that didn't use sharepoint before, and then we'll see if this is just IE Cache issue or a sharepoint bug, that is still there..

     

    Urszula

    Monday, April 14, 2008 10:46 AM
  • I have not MOSS2007 on my serverr, I'm only running Windows Sharepoint Services 3.0. But I also get the same script error when using custom content types.

     

    I tried to run KB950292 but I get the following message: "No are not products affected by this package installed on this system".

     

    Does anyone know if there is a separate package for systems running only WSS 3.0?

    Wednesday, April 16, 2008 1:37 PM
  • Microsoft says you must clear ALL CACHE especially your Browser ADD-ON cache.

     

    We originally got that Product Not Found type of error too but that was because on the test box we were deploying it to it did not already have WSS 3.0 Service Pack 1 on it.

    Wednesday, April 16, 2008 3:58 PM
  • I think that in my case, this is not a cache issue. I just tested from a new VM that has never used sharepoint before and I got that error again.. I'm thinking maybe the problem is with different language versions of MOSS and Office 2003. I have english versions of MOSS 2007 and Windows Server 2003, but I have a polish version of Office 2003.. If it's not that, than the fix just doesn't work in all scenarios and I'll have to wait for another one before I install SP1 on a production environment...

     

    Urszula

    Wednesday, April 16, 2008 9:36 PM
  •  

    I also might have language issues. I use English Office 2003 but I'm running with a Norwegian Sharepoint Services 3.0 Language package.

     

    The testusers is running office from a Terminal Server. I created a brand new user (thus with no prior IE cache) and still I get the error.

     

    I created a call at MS support so we'll see if they can assist me.

    Thursday, April 17, 2008 7:31 AM
  • Hi.

     

    I was wondering if I have a sharepoint problem.

     

    I sent this to mlb.com and they offer no solution other than to check with admin. lol!

     

    Freakin' bubble-gum generation tech support...

     

     

     

    ---

     

    I used your site last year to import data into Excel. It works quite nicely to study stats.

    This year, a bug...

    With Excel when I try import data, I get the following error. I have tried on two totally different computers as well.

    Data>Import External Data>New Web Query

    I got to www.mlb.com

    I mouse over Stats then select sortable team stats

    Then I go down below and select last seven days.

    I get this error.

    Line 79.
    Error:'document.leftNav.sitSplit.options' is null or not an object



    As I have tried on a few totally different computers, I was wondering if it is some sort of site error?



    Thanks.

    Saturday, April 19, 2008 12:22 PM
  • I applied the hotfixes for a client last week and not only did it not fix the problem, but now I get a 403 (Forbidden) error when I try to navigate to Search Settings.  To fix this problem, I had to do the following:

    From the index server (I've got a front-end web server and a backend index server, both 64 bit):

    stsadm -o search -action stop -f

    then I did

    stsadm -o search -action start -role indexquery

    then I did a:

    stsadm -o execadmsvcjobs

    Then I went back to the front end web server, navigated to the Shared Services Admin page, selected the SSP site, then from its context menu selected 'Edit Properties'. Then from the screen I reselected what the Index server was. After this, on the front end server I did a stsadm -o execadmsvcjobs.  Then search started working again (but as the index was blown away, I had to do a full reindex).

     

    Monday, April 28, 2008 12:10 AM
  •  

    I found the solution for my problem on my site a couple of days ago. Had to install a Servicepack for the Norwegian language pack. This solved my problem.

     

    Lot of thanks to John Daskalakis at Ms support John Daskalakis (even though I found the solution myselves in the end) for great patients and great support with labbing and everything. He never gave up and was quick to respond throughout the hole support call.

    Monday, May 12, 2008 8:30 PM
  •  

    Jstokka, thank you very much for posting your solution!! I figured that i didn't have sp1 for polish wss language pack, I only installed sharepoint server sp1 for polish sharepoint server language pack. So after installing the missing service pack, the problem was gone Smile
    Sunday, May 18, 2008 6:14 PM
  • Wednesday, May 28, 2008 12:16 PM
  • Please send me a download link to these hotfixes!

    kb941653
    kb950292

    thank you!
    Wednesday, July 30, 2008 4:38 AM
  • I had the Content Type "Length is Null" issue on a WSS 3.0 box with Word 2003 and XP clients.  The same process worked fine on these same clients from a test WSS 3.0 box that had been installed and patched (wss + SP1) differently. 
    So I checked the bform.js file on both boxes, and found that the file on the box that worked was newer (I didn't dig into the code). 
    I was told that hotfix 950292 was WSS only, So I took the simple path and copied that newer file to the box that was giving the error.  I also cleared the IE cache (all the settings) on the Server and both clients.
    Works like a charm right now.  I still have at lease the Infrastructure Update to apply.  I'll follow up if I get more information.
    Nicole

    Wednesday, August 27, 2008 12:59 PM
  • We have updated our sharepoint version into sp2, but the error is still there.

    It seems that the KB941653 fixed the problem, did it?
    But I can the download the file in this page http://support.microsoft.com/default.aspx/kb/941653/en-us .
    After I enter the page View and request hotfix downloads , only a SP2 file wsskb941653fullfilex86jajp can be downloaded.

    What can I do?
    Thanks in advance.
    Saturday, June 20, 2009 3:54 AM
  • It's nothing to do with ECM so moving to the normal Admin forum.
    WSS FAQ sites: http://wssv2faq.mindsharp.com and http://wssv3faq.mindsharp.com
    Total list of WSS 3.0 / MOSS 2007 Books (including foreign language) http://wssv3faq.mindsharp.com/Lists/v3%20WSS%20FAQ/V%20Books.aspx
    Saturday, June 20, 2009 10:58 AM
  • Hi,

    I ran into this very issue last week too. We had recently installed SP2 and June Cumulative Update 2009. MS Support Call asked us to install August Cumulative Update. In the meantime we restored the pre-SP2 version of the bform.js file which does work like a charm. 

    Beware, that if you have ever made any modification to the bform.js file, which by the way is not supported, that there is a big chance that a Service Pack and/or Cumulative Update will not overwrite that file and thus not fix your problem.

    Best regards,

    Dirk Van den Berghe
    www.dirkvandenberghe.com



    Tuesday, November 10, 2009 7:41 AM