122027 - Sidebar forgets items, customize has no available tabs

Status: VERIFIED FIXED

(SeaMonkey :: Sidebar, defect, P1)

Description

[Luke Koleszar]

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.

Comment 1

[[not reading bugmail]]

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

Comment 2

[[not reading bugmail]]

Attachment: screenshot of sidebar on startup

Comment 3

[[not reading bugmail]]

Attachment: another screenshot of sidebars after we hit F9 twice in browser and once in mail/news.

Comment 4

[[not reading bugmail]]

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.

Comment 5

[[not reading bugmail]]

Attachment: this change: is mail/news sidebar after hitting F9 twice.

Comment 6

[[not reading bugmail]]

Attachment: shot of customize panel is blank

Comment 7

[[not reading bugmail]]

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

Comment 8

[[not reading bugmail]]

Addressbook sidebar panel has the same problems.

Comment 9

[Luke Koleszar]

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 

Comment 10

[K Chayka]

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.

Comment 11

[[not reading bugmail]]

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.

Comment 12

[david avery]

still in a 2002012800 build on win*

seems OK on linux

Comment 13

[Mrten]

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

Comment 14

[Matthias Versen [:Matti]]

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

Comment 15

[Samir Gehani]

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.  

Comment 16

[Samir Gehani]

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]

Comment 17

[Scott MacGregor]

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. 

Comment 18

[Chris Waterson]

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...)

Comment 19

[Samir Gehani]

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.  

Comment 20

[Chris Waterson]

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.

Comment 21

[Andreas Otte]

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.

Comment 22

[Andreas Otte]

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

Comment 23

[Chris Waterson]

Attachment: proposed fix

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.

Comment 24

[Chris Waterson]

Taking bug.

Comment 25

[Chris Waterson]

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.

Comment 26

[Samir Gehani]

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

Comment 27

[Darin Fisher]

Comment on attachment 66810 [details] [diff] [review]
proposed fix

sr=darin

Comment 28

[Samir Gehani]

Comment on attachment 66810 [details] [diff] [review]
proposed fix

r=sgehani

Comment 29

[Chris Waterson]

Fix checked in. Thanks!

Comment 30

[Darin Fisher]

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.

Comment 31

[Boris Zbarsky [:bzbarsky]]

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

Comment 32

[[not reading bugmail]]

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

Comment 33

[Tracy Walker [:tracy]]

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

Comment 34

[Martin Poirier]

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