Bookmarks with blank name are wrongly exported (broken codepage symbols in the exported file)

VERIFIED FIXED in Firefox 7

Status

()

Firefox
Bookmarks & History
--
critical
VERIFIED FIXED
7 years ago
3 months ago

People

(Reporter: Virtual, Assigned: mak)

Tracking

({dataloss, regression})

Trunk
Firefox 7
dataloss, regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(3 attachments, 3 obsolete attachments)

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100902 Firefox/4.0b6pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100902 Firefox/4.0b6pre

Bookmarks with no names are wrongly imported.
Instead of blank names, they are some strange symbols.

Marking as Critical, because of strong data integration. (not data loss, but add some odd symbols to it)

Reproducible: Always

Steps to Reproduce:
1. Create e.g. bookmark on https://www.google.com/ in Bookmarks Toolbar without name to see only favicon
2. Export bookmarks to HTML file
3. Import this file
Actual Results:  
Some odd symbols in name

Expected Results:  
Properly blank name
blocking2.0: --- → ?
Could you please provide some screenshots? 

I am also facing some trouble with the Import dialog and due to this 
I am very interested in seeing this, since I cannot reproduce the 
behavior on winXP with SP3. 

juan, what do you think?

Updated

7 years ago
Keywords: qawanted
Created attachment 473433 [details]
Good
Created attachment 473434 [details]
Bad
Also with importing 4MB bookmarks.html
I get this error many times:

"A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: jar:file:///C:/Program%20Files/Mozilla%20Firefox/omni.jar!/components/nsPlacesDBFlush.js:190"
Marking as WORKSFORME, because it not happens with
Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100911 Firefox/4.0b6pre
Status: UNCONFIRMED → RESOLVED
blocking2.0: ? → ---
Last Resolved: 7 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
Version: unspecified → Trunk
Status: RESOLVED → VERIFIED
Created attachment 498331 [details]
BUG

Reopening because I exported bookmarks on XP and imported it to 7 and get this...
Status: VERIFIED → UNCONFIRMED
blocking2.0: --- → ?
OS: Windows XP → All
Hardware: x86 → All
Resolution: WORKSFORME → ---
(Assignee)

Comment 7

7 years ago
could I please get a copy of your bookmarks.html file by mail (don't attach it here since it contains sensitive data)
Also, are all of your boxes confiured with the same language? which one is it?
Is this a regression from Firefox 3.6?
(In reply to comment #8)
> Is this a regression from Firefox 3.6?

Don't know for sure, but probably yes.

(In reply to comment #7)
> could I please get a copy of your bookmarks.html file by mail (don't attach it
> here since it contains sensitive data)
> Also, are all of your boxes confiured with the same language? which one is it?

Sent (private bookmarks (less than 1%) was removed), exported with newest nightly of Firefox 4 64bit

Also I cant reproduce it anymore, only sometimes I get this funny symbols... and I don't know when this bookmarks are wrongly named, but probably on importing, not exporting
(In reply to comment #7)
> Also, are all of your boxes configured with the same language? which one is it?
Windows XP SP3 32bit Polish with Firefox 4 32bit
Windows 7 64bit Polish with Firefox 4 64bit

but this firstly occurred on exporting and importing on the same system like you can see on the first screenshots from XP
(Assignee)

Comment 11

7 years ago
So, you noticed the problem in the 64 bit version on Windows? It's even possible there is some bug there, since we don't officially support 64bit Windows version yet. Btw, the fact this is Polish (thus localized) system is probably related.
I'll try to reproduce with your file, if this doesn't always happen could be hard to reproduce though.
Awww, I didn't mention that I use Firefox in EN-US language without any language packs
(Assignee)

Comment 13

7 years ago
So, I tried importing in current nightly on Win7 x64, so far I don't see any problem, some bookmarks have japanese names, but that's expected. Maybe there's something wrong at system level with unicode fonts. It's pretty much hard to tell :(
(Assignee)

Comment 14

7 years ago
Just in case, I tried to import multiple times with the win64 version, still no luck in reproducing.
I also tried many times and can't reproduce it anymore...
odd, I simply must stop auto-updating Fx & add-ons and backuping bookmarks next time when I see this to diagnose it completely ;p

so marking this RESOLVED WORKSFORME for now
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → WORKSFORME
blocking2.0: ? → ---
OK, bug still exist on importing bookmarks with blank name from file  bookmarks.html.
Tested on Portable Firefox 3.6.15 and latest Firefox4b13pre 64bit nightly on Win 7 64bit.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Version: Trunk → 3.6 Branch
Created attachment 517152 [details]
bookmarks.html
Created attachment 517153 [details]
BUG2
Keywords: dataloss
Version: 3.6 Branch → unspecified
I see that this odd symbols in importing are caused by probably wrong exporting and writing some wired symbols instead of nothing

Example:

is
<DD>Wasz spob na studia
        <DT><A HREF="http://10minutemail.com/" ADD_DATE="1268738723" LAST_MODIFIED="1295440860"></A>

should be
<DD>Wasz spob na studia
        <DT><A HREF="http://10minutemail.com/" ADD_DATE="1268738723" LAST_MODIFIED="1298058452"></A>
blocking2.0: --- → ?
Summary: Bookmarks with blank name are wrongly imported → Bookmarks with blank name are wrongly exported/imported
Version: unspecified → Trunk
This wouldn't block release, if it gets confirmed we could consider it as a .x issue.
blocking2.0: ? → -
(Assignee)

Comment 21

6 years ago
the bookmarks.html file has the same symbols, so importing seems correct.
The problem seems to be in exporting then?
Unfortunately this bug is still missing steps to reproduce the issue starting from a new clean profile, if you could find a certain page that once bookmarked and exported causes a broken bookmarks.html file, that would be useful.
Severity: critical → normal
Yep looks like exporting is the problem. But I can hardly reproduce it. Once when I see that a bug occur I tried second time and it didn't happen anymore.

I will try with clean profile and new created bookmarks to give you guys detailed info.
Summary: Bookmarks with blank name are wrongly exported/imported → Bookmarks with blank name are wrongly exported
(Assignee)

Updated

6 years ago
Duplicate of this bug: 645724
(Assignee)

Comment 24

6 years ago
confirming for investigation of what could cause broken codepage symbols in the html file.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Bookmarks with blank name are wrongly exported → Bookmarks with blank name are wrongly exported (broken codepage symbols in the exported file)

Comment 25

6 years ago
I first experienced this problem with Firefox 4.0 (after upgrading from 3.6) on Win 7 64-bit.  It occurs in the file generated by autoExportHTML.  It happens nearly every time.  The problem does not occur for me when I manually export my bookmarks to html.

I'd be happy to email files from my profile to one of the developers, if it might help.
(Assignee)

Comment 26

6 years ago
which locale is your OS and your Firefox?
Sure, I'd be interested in getting your places.sqlite by mail to try to reproduce if filesize allows sending it.

Comment 27

6 years ago
Sorry, I misspoke - I have *32* bit Win 7 Professional.  I believe all the locale stuff is US English.  (I don't remember where to check to confirm that.)  I will email a zip of my places.sqlite.
What's the status in diagnosing this bug guys ?
Branching is in a week for Firefox 6.
(Assignee)

Comment 29

6 years ago
(In reply to comment #28)
> Branching is in a week for Firefox 6.

And then there will be 7 in 6 weeks, 8 in 6 weeks... we have a lot of work to do and not enough resources for every single bug. You're welcome to investigate the bug and make a patch if you wish, but as you said it's hard to reproduce, and that doesn't help.

Btw, looks like I never received the places.sqlite file :(
Awww, I think you got already Rod Spades' places.sqlite file on your email to investigate it.

So Rod Spade could you resend this file to Marco Bonardo ?

Also sorry for bugspam, but I want only remind some critical (like this) or easy fix (about bookmark button) bugs.

Comment 31

6 years ago
> So Rod Spade could you resend this file to Marco Bonardo ?

Done.
(Assignee)

Comment 32

6 years ago
got it, was wrongly marked as spam :(
(Assignee)

Updated

6 years ago
Duplicate of this bug: 657099
(Assignee)

Comment 34

6 years ago
OK, I got it! I introduced this bug in importexport code in bug 420729. Looking at it, it's probably a typo on my side since I didn't mean to change this behavior (most likely I moved a brace and then moved it back to the wrong position).

Thank you very much for the places.sqlite file, I was unable to reproduce the bug with it, but as soon as I added an empty titled bookmark it became reproduceable.

I'll try to make a test, but due to the nature of the bug (using uninitialized memory) it may work only randomly.
Assignee: nobody → mak77
Blocks: 420729
Status: NEW → ASSIGNED
Flags: in-testsuite?
Keywords: regression

Comment 35

6 years ago
Thanks guys for all the work you do. 
I'm not a programmer, just a user.  I enjoy Fx every day - all the more so when I'm forced to use another browser - whose name I won't mention - for sites that work only with it ..
(Assignee)

Comment 36

6 years ago
Created attachment 537987 [details] [diff] [review]
patch v1.0

To briefly explain what happens here:
- we are accessing uninitialized memory due to a missing '\0' when name is empty
- to test this I had to refactor the test
- the more complete test catched a bug causing dateAdded and lastModified to be ignored when importing to a folder, so I had to fix this as well, to have the test pass.

but I've been able to enable all the commented out subtests, so more testing!
Attachment #498331 - Attachment is obsolete: true
Attachment #517152 - Attachment is obsolete: true
Attachment #517153 - Attachment is obsolete: true
Attachment #537987 - Flags: review?(dietrich)
Comment on attachment 537987 [details] [diff] [review]
patch v1.0

r=me. this looks fine. thanks for taking the time to fix those tests!
Attachment #537987 - Flags: review?(dietrich) → review+
(Assignee)

Comment 38

6 years ago
http://hg.mozilla.org/projects/places/rev/1ef9f5d0795b
Whiteboard: [fixed-in-places]
(Assignee)

Comment 39

6 years ago
http://hg.mozilla.org/mozilla-central/rev/1ef9f5d0795b
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago6 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 7
At first glance looks fixed.
Thank you!

VERIFIED
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:7.0a1) Gecko/20110609 Firefox/7.0a1

Shouldn't this be pushed to next stable (Firefox 5) ?
Status: RESOLVED → VERIFIED
Flags: in-litmus?
Whiteboard: [fixed-in-places]
(Assignee)

Comment 41

6 years ago
(In reply to comment #40)
> At first glance looks fixed.
> Thank you!

No, thanks always go to people who helped reporting and reproducing the bug, for patience and for trying to bring this on in a constructive way. Fixing it is the easy part often.

> Shouldn't this be pushed to next stable (Firefox 5) ?

Well, Firefox 5 is pretty hard (I'd say impossible) to do since it's already in beta stage.
Firefox 6 may be possible, but I'd not put a bet on that.  Even if I don't like the bug at all (using uninitialized memory is always bad) it's something that happens in edge cases, when you have empty-named bookmarks.  But don't be too much worried, releases happen every 6 weeks, so you won't have to wait like for previous major releases and Firefox 6 will soon be a beta.

Updated

6 years ago
Flags: in-litmus?
Blocks: 731663

Comment 42

4 years ago
64 bit windows 7 doesn't seem to work.
Severity: normal → critical
You need to log in before you can comment on or make changes to this bug.