496717 - XUL Template Builder cannot rebuild with Places datasource once database has changed

Status: RESOLVED WORKSFORME

(Firefox :: Bookmarks & History, defect)

Description

[Adam]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042807 Iceweasel Firefox/2.0.0.4 (Debian-3.0.9-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090605 Shiretoko/3.5pre

Once Firefox has accessed its Places database it seems to acquire some kind of lock or some other problem occurs that precludes an XUL Template from using it as a datasource.

Reproducible: Always

Steps to Reproduce:
01. Create a new profile
02. Install any extension (I used Firebug, so further directions will use it as example)
03. Restart and then close (so the extension's fully installed)
04. Copy the provided bug.xul and bug.js (see attachments) to the extension's content folder
    In the case of Firebug that's extensions/[e-mail]/content/firebug
05. Start Firefox
06. Open the bug.xul in the location bar.
    For Firebug that's chrome://firebug/content/bug.xul
07. Note the list is built and there are items present.
08. Right click on the "Getting Started" item in the Bookmarks Toolbar
09. Select "Properties" and modify the name of the bookmark.  Save.
10. Click the "rebuild" button in the bug.xul pane.

Actual Results:  
All generated content disappears.

Expected Results:  
The content to be rebuilt with the updated data.

You can go to about:config and set javascript.options.showInConsole to true; then the error console will display an error: "builder is null"

You can also restart Firefox and this time modify a bookmark before ever opening the bug.xul.  Then when you open it, the content is not initially built.

Comment 1

[Adam]

Attachment: XUL file containing XUL Template to build from Places DB

Should use with accompanying bug.js

Comment 2

[Adam]

Attachment: Simple function that will call rebuild() for the XUL Template in bug.xul

Use with accompanying bug.xul

Comment 3

[Benjamin Smedberg]

I think this is by design/WONTFIX, but I'll let Shawn chime in.

Comment 4

[Adam]

The method for accessing the Places database through script has changed[1].  The XUL Template code accesses the SQLite datasources with the older method.  Around nsXULTemplateQueryProcessorStorage.cpp:216 [2] is where the XUL Templates would need to branch for Places and use the new method.

At nsXULTemplateQueryProcessorStorage.cpp:224 there is a branch for "profile:" datasources.  Could another branch be added ("places:") for accessing the Places datasource through XUL Templates?  Would there be some other way to differentiate the Places datasource and use the new method for it?

Thanks.

1. https://developer.mozilla.org/En/Updating_extensions_for_Firefox_3.5#Accessing_the_Places_database
2. http://mxr.mozilla.org/mozilla1.9.1/source/content/xul/templates/src/nsXULTemplateQueryProcessorStorage.cpp#216

Comment 5

[Shawn Wilsher :sdwilsh]

(In reply to comment #3)
> I think this is by design/WONTFIX, but I'll let Shawn chime in.
It is to a point.  We don't let arbitrary connections to be opened to the database file, and that's how it the template builder code gets to the database.

There's no way to work around this as far as I know.  This has been like this since at least beta 2, maybe beta 1.  Had this been found earlier, we may have been able to fix it...

Comment 6

[Adam]

I'll take the blame for not filing this sooner.  I actually tracked it down to the August 17, 2008 build last October.  I had e-mailed you explaining the behavior I was getting and asking for advice on debugging it to determine if it was my extension causing the problem, as well as asking for help in #extdev.  Unfortunately I've not had much time to work on my extension since then, and I am only now getting back to it.

As this hasn't been reported before now it's likely I'm the only one affected, but it might be helpful to add a note about it to the information [1] for updating extensions for 3.5.  Hopefully this can be fixed for 3.6.

1. https://developer.mozilla.org/En/Updating_extensions_for_Firefox_3.5

Comment 7

[Dietrich Ayala (:dietrich)]

Yes, we should fix this for 3.6 at the latest. We should try to get in a maintenance release for 3.5.

Comment 8

[Samuel Sidler (old account; do not CC)]

(In reply to comment #7)
> Yes, we should fix this for 3.6 at the latest. We should try to get in a
> maintenance release for 3.5.

Then it needs an owner pretty soon...

Comment 9

[Adam]

https://bugzilla.mozilla.org/show_bug.cgi?id=460896#c4 offers a workaround.  The workaround is fine for me.

Comment 10

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv

Comment 12

[Marco Bonardo [:mak]]

we don't lock the database anymore