From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.8+) Gecko/20020126 BuildID: 2002012608 As of the 2002-01-26 build, sidebar is badly broken. In the first window only two of my sidebar items appear, in all other windows the sidebar is empty. The Customize Sidebar window appears with no items in the Availabe Tabs or Tabs in Sidebar sections. Reproducible: Always Works with 2002012503. The Sidebar items are still there if you go back to a previous version.

I'm not sure if the fixes for bug 116094 and bug 119975 made it into the 1-26-08 build for windows.

one more thing: if you try build 1-26-08 on a new profile tabs button is there in the second screenshot, if you try this with a profile even from build 1-25 tabs button is not there on the browser sidebar. I'm seeing this on w2k also. Samir, did the two bug fixes get into this build? And is there a possible problem with one of the patches. Thanks.

taking a guess that bug 122027 fixes up some of this.

Addressbook sidebar panel has the same problems.

This problem still exists with trunk build 2002012708 (WinME), but it does NOT happen with today's (2002-01-27) 0.9.8 branch build. May be related to bug 119975

win32 build 2002012608, win98se Opening and closing the sidebar in the browser gives errors in the js console: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIRDFService.GetDataSource]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://communicator/content/sidebar/sidebarOverlay.js :: anonymous :: line 463" data: no] In my case, only 2 tabs show (bookmarks and one custom tab). The bookmark entries show when I click on that tab, but the cutsom tab is completely empty.

here are the JS errors for the browser window sidebar in the 1-27-08 w2k build... in this order on my JS console. -> this is for F9 twice Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIRDFService.GetDataSource]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://communicator/content/sidebar/sidebarOverlay.js :: anonymous :: line 463" data: no] ----------------- Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIRDFService.GetDataSource]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://communicator/content/sidebar/sidebarOverlay.js :: SidebarBuildPickerPopup :: line 1013" data: no] ------------- Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIRDFService.GetDataSource]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://communicator/content/sidebar/sidebarOverlay.js :: SidebarTogglePanel :: line 1031" data: no] ------------- Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIRDFService.GetDataSource]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://communicator/content/sidebar/customize.js :: sidebar_customize_init :: line 80" data: no] Source File: chrome://communicator/content/sidebar/customize.js Line: 80 -------------- Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIRDFService.GetDataSource]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://communicator/content/sidebar/sidebarOverlay.js :: sidebar_overlay_init :: line 615" data: no] Source File: chrome://communicator/content/sidebar/sidebarOverlay.js Line: 615 -- after you hit sidebar F9 twice, tabs button disappears.

still in a 2002012800 build on win* seems OK on linux

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

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

The patches for bugs 119975 and 110694 were checked in on the afternoon of 2002-01-26 and can therefore be ruled out as causes for this bug. Note that this bug does not manifest on the mozilla0.9.8 branch (where the patch for bug 119975 was checked in as well). Investigating why the |GetDataSource()| call fails.

Beginnig to suspect a change in RDF code since the MIME-types-datasource-changing code in the ``Navigator | Helper Applications'' pref panel is giving the same exception when we are trying to get the mimetypes.rdf datasource. Try adding a MIME type mapping and clicking OK in the ``New Type'' dialog. Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIRDFService.GetDataSource]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://communicator/content/pref/pref-applications-new.js :: onOK :: line 102" data: no]

samir, that mime type issue was a smoketest from earlier this morning that has already been fixed. An old CID for the mime service was removed and they are now using a contract ID. So that issue was totally isolated to the mime data source. it shouldn't effect this bug unless the sidebar is also trying to load the mime data source via a class ID instead of a contract ID. Given the location of the assertion in sidebarOverlay.js, it doesn't look like that's the case but I could be wrong.

This appears to be a windows-only problem. The problem appearst to be that datasource that it's trying to load has a different spec before and after being canonified into a URI. The call to GetDataSource passes this as the URI: file://C:/DOCUMENTS%20AND%20SETTINGS/ADMINISTRATOR/APPLICATION%20DATA/MozillaUsers50/default/uaau5954.slt/panels.rdf which gets canonified to: file:///C:/(etc.) Note the three slashes after the `file:'. I doubt the `file:' URI parsing code has changed (cc'ing darin to be sure), and the URI _should_ have three slashes follwing the protocol spec. Has the front-end code changed? (It looks like it's requesting a bogus URI to me...)

Sidebar front-end code did not change during the period this bug occured. There were some changes to URL resolution code for bug 119071 and bug 120959.

Well, the RDF service hasn't kept pace with the times. It should probably be using nsIURI objects as keys, instead of naked strings. That would avoid the canonification problem that we're having now. I'll see if I can wallpaper over the problem in the RDF back-end.

Nothing on the patches in both bugs is windows specific. bug 120959 takes only effect if the url ends in /.. or /. And if it is bug 119071 it points to a bogus url that is no longer silently corrected, but again nothing windows specific here.

The change from file:// to file:/// is in the urlparser code for ages now. I don't believe that this could be the reason.

This patch canonifies the URI before attempting to look it up in the cache. Canonification may fail, because some datasources are given `URIs' that aren't really URIs, like `rdf:bookmarks'. It also modernizes some of the string- and component-fu in nsRDFService::GetDataSource.

Taking bug.

Maybe we recently added URI canonification code to nsRDFXMLDataSource? Anyway, it doesn't matter. A latent bug was exposed here that would've caused problems sooner or later.

BTW, backing out the fix for bug 109179 fixes this bug: cvs update -j1.4 -j1.3 mozilla/netwerk/base/src/nsIOServiceWin.cpp

Comment on attachment 66810 [details] [diff] [review] proposed fix sr=darin

Comment on attachment 66810 [details] [diff] [review] proposed fix r=sgehani

Fix checked in. Thanks!

i think i understand what was wrong with my checkin for bug 109179. i was prepending file:// instead of file:/// for windows paths. this was an unfortunate carry over from the unix version of the patch in which file:// is correct. i'll be adding a patch to bug 109179 to resolve this. waterson's patch is still good since URLs should always be canonified before being used as a key.

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

Chris, and the rest of the team, Thank You!

This is fixed as seen on windows commercial build 2002-01-29-06-trunk.

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