Closed Bug 241987 Opened 20 years ago Closed 20 years ago

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

Categories

(SeaMonkey :: Bookmarks & History, defect)

defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mozilla, Assigned: mfe)

References

Details

(4 keywords, Whiteboard: [have patch] - ready for checkin ben)

Attachments

(2 files)

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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
*** Bug 250001 has been marked as a duplicate of this bug. ***
Also seing this on XP with build 20040727 
Severity: normal → major
Flags: blocking-aviary1.0PR?
WFM

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040728
Firefox/0.9.1+
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.
OS: Linux → All
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.
Product: Browser → Firefox
(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.
Product: Firefox → Browser
*** Bug 253930 has been marked as a duplicate of this bug. ***
I'm guessing it might have something to do with bug 252053 -- Cc'ing dwitte.
these were filed on builds waaay before safestream landed, but of course that
means that safestream might have fixed it already ;)
Flags: blocking-aviary1.0?
+ for 1.0 - should not have functionality that does not work. 
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0+
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
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. ;) 
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.
Flags: blocking1.7.3+
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.
Flags: blocking1.7.3+
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
Blocks: 255069
(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. ;-)
Keywords: useless-UI
*** Bug 256751 has been marked as a duplicate of this bug. ***
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.)
Hardware: PC → All
> fwiw, this was working for me on Mac using 2004071622-0.9+ bits.

clarifying: was using firefox aviary1.0 branch bits.

As I said before, I'm not sure that this is the correct solution but it works.
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).
Flags: blocking-aviary1.0PR- → blocking-aviary1.0PR?
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 on attachment 157276 [details] [diff] [review]
Patch for firefox aviary

vald/ben,  can you have a look?
Attachment #157276 - Flags: superreview?(bugs)
Attachment #157276 - Flags: review?(vladimir)
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR+
Whiteboard: [have patch] - need review ben/vlad
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.
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 on attachment 157276 [details] [diff] [review]
Patch for firefox aviary

r=vladimir@pobox.com

Looks fine to me, though fixing it inside the bookmarks service export function
might be better.  It'll do for now.
Attachment #157276 - Flags: review?(vladimir) → review+
Whiteboard: [have patch] - need review ben/vlad → [have patch] - need review ben
Comment on attachment 157276 [details] [diff] [review]
Patch for firefox aviary

sr=ben@mozilla.org
Attachment #157276 - Flags: superreview?(bugs) → superreview+
Are bug 255515 and bug 256751 same problem?
*** Bug 255515 has been marked as a duplicate of this bug. ***
Whiteboard: [have patch] - need review ben → [have patch] - ready for checkin ben
-> Daniel Lindkvist
Assignee: p_ch → gorgias
checked in seamonkey, firefox trunk and branch
marking fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
(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...
Keywords: fixed-aviary1.0
(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).
*** Bug 255069 has been marked as a duplicate of this bug. ***
verified with Windows Firefox branch build 2004-09-09-08-0.9
Status: RESOLVED → VERIFIED
*** Bug 256751 has been marked as a duplicate of this bug. ***
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)
Product: Browser → Seamonkey
*** Bug 260298 has been marked as a duplicate of this bug. ***
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
Here is a patch for the Mozilla 1.7 branch.
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.
Attachment #175040 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #175040 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #175040 - Flags: approval1.7.6?
Comment on attachment 175040 [details] [diff] [review]
Patch for 1.7 Branch

preapproving since it makes us match firefox
Attachment #175040 - Flags: approval1.7.6? → approval1.7.6+
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.
Attachment #175040 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #175040 - Flags: review?(neil.parkwaycc.co.uk)
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 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??
Keywords: fixed1.7.6
(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.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: