241987 - Export bookmarks doesn't save the bookmarks to a file like bookmarks.html

Status: VERIFIED FIXED

(SeaMonkey :: Bookmarks & History, defect)

Description

[Anco]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a) Gecko/20040428
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a) Gecko/20040428

As a common user I tried to export my bookmarks to my home folder. No errors are
given, but the file isn't in my folder. Then I tried it as user "root" no
difference. Than I tried it with mozilla 1.6 no problem exporting my bookmarks
directly worked. Than I tried exporting bookmark within mozilla 1.7 build
2004031616 on WINXP no problem. It seems only not working on Linux. My linux is
Redhat 9, I also just tried on Mandrake 10 and have the same problem.

Reproducible: Always
Steps to Reproduce:
1.export bookmarks
2.choose folder and give name (default is okay) click on OK
3.Look in the folder and see no file is created????

Actual Results:  
On Linux I can export my bookmarks with mozilla 1.6 So that's my temporaly solution.

Expected Results:  
Make the bookmarks.html file in the folder which is choosen.

Comment 1

[Stefan Borggraefe]

Confirming with a self-made Linux trunk build from today and 1.7-branch build
20040428 (also Linux).

I see the following on the console when Mozilla tries to export the bookmarks:

###!!! ASSERTION: null data pointer: 'Not Reached', file nsTSubstring.cpp, line 549
Break: at file nsTSubstring.cpp, line 549
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsBookmarksService.cpp,
line 5455
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80520006
(NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIRDFDataSource.DoCommand]"  nsresult:
"0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)"  location: "JS frame ::
chrome://communicator/content/bookmarks/bookmarks.js :: anonymous :: line 390" 
data: no]
************************************************************
An error occurred executing the cmd_bm_export command

Bug 236003 may be related.

Comment 2

[R.K.Aa.]

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

Comment 3

[José Jeria]

Also seing this on XP with build 20040727 

Comment 4

[Peter van der Woude [:Peter6]]

WFM

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040728
Firefox/0.9.1+

Comment 5

[Markus Lindström]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040728 Firefox/0.9.1+

Confirming bug, even present with a new profile. Very annoying, this. Changing
OS to All as this has been noted on Windows as well as Linux.

Comment 6

[Markus Lindström]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040728 Firefox/0.9.1+
Exporting bookmarks works on Firefox trunk.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040728
Also working in latest Seamonkey nightly.

Changing product to Firefox, as this seems to be an Aviary-only issue.

Comment 7

[Stefan Borggraefe]

(In reply to comment #6)
> Changing product to Firefox, as this seems to be an Aviary-only issue.

Not true, see comment 0 and comment 1. This also happens with Seamonkey. I still
see the same error message both with 1.7-branch and 1.8-trunk builds on Linux.
The bookmarks.html file is not saved.

Comment 8

[José Jeria]

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

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I'm guessing it might have something to do with bug 252053 -- Cc'ing dwitte.

Comment 10

[[e-mail]]

these were filed on builds waaay before safestream landed, but of course that
means that safestream might have fixed it already ;)

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

+ for 1.0 - should not have functionality that does not work. 

Comment 12

[Keith Hopkins]

Still seen in 1.7.2 (Linux)

Manage Booksmarks / Tools / Export / select filename, click Save.

Error: [Exception... "Component returned failure code: 0x80520006
(NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIRDFDataSource.DoCommand]"  nsresult:
"0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)"  location: "JS frame ::
chrome://communicator/content/bookmarks/bookmarks.js :: anonymous :: line 390" 
data: no]
Source File: chrome://communicator/content/bookmarks/bookmarks.js
Line: 390

Comment 13

[Žiga Sancin]

Yes, happens on aviary branch build 20040810 on win2k. However, there is
something interesting here... If you already have a file called like the file
you would like to export, as expected the dialog appears with a warning about
the existing file, and the file gets overwritten! So, here is a temporary
workaround. Make a .html file to which you want to export your bookmarks, name
it like the bookmarks export html file, export bookmarks, and confirm the
warning dialog. What a beautiful workaround. ;) 

Comment 14

[Eric Valette]

I can confirm this bug on self build mozilla 1.7 and on the debioan 1.7.2-2
version. I tried to export my bookmark file to a windows writeable folder and
then on /tmp under bookmark.html.

Comment 15

[Stefan Borggraefe]

Eric: You're not allowed to set blocking-flags to +. Only drivers are allowed to
do that. What you can do is requesting blocking status by setting the flag to ?.
Drivers will then decide if this bug should block the release and change the
flag to + or - accordingly.

Comment 16

[Daniel Lindkvist]

My interpretation is that nsBookmarksService::WriteBookmarks expects to get an
existing file as an argument but there is no such file when one tries to do an
export. 

I see two possible solutions depending on how this is supposed to work, either
create the file in bookmarks.js->exportBookmarks (I have tried this and it
works) or add a check in nsBookmarksService::WriteBookmarks something like:
if (!aBookmarksFile) aBookmarksFile->Create

Comment 17

[Jeff Walden [:Waldo]]

(In reply to comment #16)
Daniel, would you consider making a patch (or two, if you're not sure which impl
is the correct one)?  Seeing as we've already removed at least two bits of
semi-broken UI from Firefox for 1.0(PR), this seems like something that should
really be fixed (if it can be done quickly, which it seems it can be) so it's
not "unusably broken".  I'm sure Ben would reconsider the 1.0PR- and add a patch
in time for 1.0PR if he likes it (or even as a stopgap for the branch).

Also, while I'm making a (hopefully) useful comment that'll get sent to everyone
already, it's time to fulfil a goal of mine in bmo...find a valid use for the
useless-UI keyword. ;-)

Comment 18

[José Jeria]

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

Comment 19

[sairuh (rarely reading bugmail)]

fwiw, this was working for me on Mac using 2004071622-0.9+ bits. (cannot get a
narrower regression window as I cannot find builds earlier than 7/29 on the ftp
site.)

Comment 20

[sairuh (rarely reading bugmail)]

> fwiw, this was working for me on Mac using 2004071622-0.9+ bits.

clarifying: was using firefox aviary1.0 branch bits.

Comment 21

[Daniel Lindkvist]

Attachment: Patch for firefox aviary

As I said before, I'm not sure that this is the correct solution but it works.

Comment 22

[Jeff Walden [:Waldo]]

The attached patch would fix this bug.  The author doesn't know if it's the
correct approach, but it would make the feature work for 1.0PR.  Considering
we've removed other features because of outstanding enhancement requests, I
don't see a reason not to fix this for PR.  After 1.0PR it could be fixed more
correctly (if needed).

Please reconsider this, because the menu item's useless right now (and there's
now a patch, when there wasn't one before).

Comment 23

[amano]

Why not simply ask for review and aviary approval? Daniel, since this is your
patch, can you set the proper flags?

I don't see why quick fixes and hacky workarounds should not be used on the
aviary branch. You have the trunk for doing stuff the right way.

Comment 24

[chris hofmann]

Comment on attachment 157276 [details] [diff] [review]
Patch for firefox aviary

vald/ben,  can you have a look?

Comment 25

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 157276 [details] [diff] [review]
Patch for firefox aviary

Can you not prefix local variable names with "a"...? it makes the code
confusing ;-) I won't make you attach a new patch for that though.

Comment 26

[Robin Lu]

mozilla 1.7 branch and seamonkey also have the bug. Is there anybody working on
that? Or I'd like to port Daniel's patch to seamonkey.

Comment 27

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 157276 [details] [diff] [review]
Patch for firefox aviary

r=[e-mail]

Looks fine to me, though fixing it inside the bookmarks service export function
might be better.  It'll do for now.

Comment 28

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 157276 [details] [diff] [review]
Patch for firefox aviary

sr=[e-mail]

Comment 29

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 157276 [details] [diff] [review]
Patch for firefox aviary

sr=[e-mail]

Comment 30

[Anbo Motohiko]

Are bug 255515 and bug 256751 same problem?

Comment 31

[José Jeria]

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

Comment 32

[Pierre Chanial]

-> Daniel Lindkvist

Comment 33

[Pierre Chanial]

checked in seamonkey, firefox trunk and branch
marking fixed.

Comment 34

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #25)
> (From update of attachment 157276 [details] [diff] [review])
> Can you not prefix local variable names with "a"...? it makes the code
> confusing ;-) I won't make you attach a new patch for that though. 

it looks like this was not fixed when the patch was checked in, neither in the
seamonkey nor in the firefox file...

Comment 35

[Pierre Chanial]

(In reply to comment #34)
> it looks like this was not fixed when the patch was checked in, neither in the
> seamonkey nor in the firefox file...

good catch. I checked in a correction (seamonkey, ff trunk and branch).

Comment 36

[José Jeria]

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

Comment 37

[Tracy Walker [:tracy]]

verified with Windows Firefox branch build 2004-09-09-08-0.9

Comment 38

[Jeff Walden [:Waldo]]

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

Comment 39

[Mike Kaply [:mkaply]]

For the record, there was no xpfe patch to bookmarks.js in this bug, hence this
bug was never reviewed/superreviewed to change anything but browser. The changes
that were made to xpfe/bookmarks.js were unapproved/reviewed.

Please attach an xpfe patch so this patch can go in Mozilla 1.7 if necessary.

(Yes I realize the patch is the same - it's still the process)

Comment 40

[Hiro]

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

Comment 41

[Eric Valette]

Bug is still there on Debian Linux (sid) with mozilla 1.7.5...

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1

Comment 42

[Philip K. Warren]

Attachment: Patch for 1.7 Branch

Here is a patch for the Mozilla 1.7 branch.

Comment 43

[Philip K. Warren]

Comment on attachment 175040 [details] [diff] [review]
Patch for 1.7 Branch

This patch has already been checked in on the trunk and the aviary branch -
this is the same patch but for the Mozilla 1.7 branch.

Comment 44

[Mike Kaply [:mkaply]]

Comment on attachment 175040 [details] [diff] [review]
Patch for 1.7 Branch

preapproving since it makes us match firefox

Comment 45

[Philip K. Warren]

Comment on attachment 175040 [details] [diff] [review]
Patch for 1.7 Branch

mkaply says to just carry over existing firefox reviews for this patch which is
already checked in on the aviary branch and the trunk.

Comment 46

[Philip K. Warren]

Checked in on Mozilla 1.7 branch:

Checking in bookmarks.js;
/cvsroot/mozilla/xpfe/components/bookmarks/resources/bookmarks.js,v  <-- 
bookmarks.js
new revision: 1.128.2.1; previous revision: 1.128
done

Comment 47

[[e-mail]]

Comment on attachment 157276 [details] [diff] [review]
Patch for firefox aviary

So, you eschewed the file picker's file in favour of creating a new one. And
this got reviewed? Twice??

Comment 48

[Philip K. Warren]

(In reply to comment #47)
> (From update of attachment 157276 [details] [diff] [review] [edit])
> So, you eschewed the file picker's file in favour of creating a new one. And
> this got reviewed? Twice??

Bug 283227 filed for this cleanup.