Some users have reported having to "continue" several times with large bookmark files.

As a Plan B, consider importing the file to IE and then having Firefox pick up the IE Favorites.

jscher2000 said

Some users have reported having to "continue" several times with large bookmark files.

Would that be specific to version 42 or 43 ? What baffles me is that I tested the import before (that must have been with v.40.0.3), and there was no discernible delay to speak of, even with such a big file. How long would have one to wait ? There's no progress indicator, nothing.

I should add that at some point, some import did occur. However, since I did not notice how it happened and there was this hang-up before, I did not want to risk importing half my bookmarks, so I deleted them and started all over again.

As a Plan B, consider importing the file to IE and then having Firefox pick up the IE Favorites.

Would that retain the comments ? I have some comments generated under Opera, and they import nicely into Firefox (when the import works...).

This is very unsettling. I live by my bookmarks. I need to rely on the import-export mechanism for backups, in order to switch to other browsers if need be, etc. I thought using html as a pivot format was a rock-solid, universal option...

Clairvaux said

jscher2000 said

Some users have reported having to "continue" several times with large bookmark files.

Would that be specific to version 42 or 43 ?

Probably not that recent. I've only seen this problem raised once or year or so. Not that I can read every thread!

Would that retain the comments ?

I don't know if or how comments are stored in IE Favorites.

I have just tested the import of the same .html favorites file into Opera v.33, and it takes 1 second. This new-generation Opera is almost useless for other reasons, but it shows that the file is OK.

It's a 2,5 Mb file by the way, which is quite small in absolute terms, the way files go nowadays.

All right, I found a strange workaround (sort of), but I still need the community's help on this.

I managed to import the bookmark file by using Windows Safe Mode (not Firefox Safe Mode). Here's how.

• Start Windows in Safe Mode.
• Start Firefox normally.
• Library, Import bookmarks from HTML.
• Firefox runs normally without freezing.
• I did get a single Unresponsive Script message.
• Continue.
• Bookmarks get imported after 10 to 20 seconds. Nothing like the very long wait I had experienced before, with no result.

Wanting to test that again, I did the following :

• Delete the whole folder I had just imported.
• Firefox runs normally without freezing.
• Another Unresponsive Script message.
• Continue.
• The folder is deleted in a matter of seconds.

Then again :

• Import bookmarks from HTML.
• No Unresponsive Script message this time.
• Bookmarks get imported in maybe 10-20 seconds, once again.
• Reboot, all is fine.

Any ideas about this ? I need to export / import bookmarks as a matter of routine, including in the .html format, so i can't rely on Windows Safe Mode for that.

Windows Safe Mode typically skips over software that starts usually automatically, including perhaps real-time antivirus software.

I doubt it's anti-virus. Windows Safe Mode did not suppress the problem, merely made it more tolerable : I did get "Unresponsive Script" messages. Besides, I had already tried to shut off active shields of Avast under normal mode, and it didn't change anything.

I see a lot of complaints when googling "Firefox bookmarks unresponsive script", spanning many years, and I did not find anybody who had solved the problem. The only workarounds I found were :

- Copy over your old .sqlite file (or whatever the native bookmarks file is), instead of importing the .html file. But that's not solving the problem. I need to import this file. In html format.

- Tweak some delay relative to scripts in about:config, import the file, than tweak it back. But the "Unresponsive Script" alert would still come up, and the user who said he "solved" the problem thus said he still had to click away 15-16 times on those warnings, with God knows how much wait in-between !

By the way, I did try to go through IE, but it froze in a similar manner, so I aborted it.

Clairvaux said

Firefox goes into non-responding mode when I'm trying to import my HTML backup file of bookmarks.

Was that bookmarks.html file created by Firefox, like via an "Export" from Firefox?

Or is that a bookmarks.html file from another web browser?

Based upon my "fiddling around" experience years ago when Firefox 3.0 first got the places.sqlite scheme for bookmarks / history, I found that a bookmarks.html file that didn't contain the Favicon "images" a 2.5 Mb bookmarks.html file was "huge", even with only the hyperlinks and comments.

Whereas with an "Export in HTML" bookmarks. html file from any version of Firefox would make 2.5Mb rather a small number of bookmarks. The Favicon "images" (stored in data:image/png;base64 format - not as a "real image file" like png or jpg) in a Firefox generated bookmarks.html file might be as much as 95% of the content of the bookmarks.html file. https://en.wikipedia.org/wiki/Data_URI_scheme#HTML

BTW, that data:image/png;base64 format for Favicon storage wasn't part of the original < !DOCTYPE NETSCAPE-Bookmark-file-1 > spec that became the unofficial "export / import" file type that has been used by most browsers for the last 20 years or so. It was added by Mozilla in 2004 to Firefox 0.9 - it is unique to Firefox and other Gecko-based browsers that use Gecko from Mozilla, AFAIK.

The point that I'm trying to make is that 2.5Gb isn't relative to the number of bookmarks in that bookmarks.html file. Small number if it includes Favicon data, while it could be a large number if it has no Favicon data. The difference might be a factor of 10, as I recall.

As far as a possible "solution" for you, try could this ... but I suspect that it may not work any longer due to recent changes in Firefox. I don't see a bookmarks.html file appearing in a new Profile that I create, but Firefox still does receive the "default" set of bookmarks that was supplied in a bookmarks.html file in the past, and that file would be in the Profile folder.

Try this .... Create a new Profile and with Firefox closed, delete the places.sqlite file and whatever json backup files may exist in the /bookmarkbackups/ folder. Then place that bookmarks.html file. Then start Firefox and see what happens.

I figure that when you launch Firefox and it discovers that the places.sqlite file is missing, that it will "look" to the /bookmarbackups/ folder for the latest json backup file; when one isn't found, Firefox should use that bookmarks.html file of yours. As it does on "first-run" upon installation or when a new Profile is created.

Hope that gets you beyond that 'hung' script problem. If it doesn't work, sorry about wasting your time ....

Thanks for your thoughts, Edmeister.

As I mentioned, this bookmarks file was exported from Opera (legacy version), since that was my regular browser before my latest reinstall and migration to Firefox. It has years and years of bookmarks, and inherited those I created while I was loyal to Maxthon (another long period).

It's big in terms of number of bookmarks (around 15 000, I think), but small in terms of size (2,5 Mb in .html form) -- at least it seems to me that's a small file by todays' standards ; my previous Microsoft Outlook .pst file was 2,5 Gb -- admittedly .pst files tend to be huge, and can even (theoretically) reach the terabyte range.

It almost certainly doesn't have favicons in it, since they appear blank in Firefox, and are only recreated once I've visited a link.

I like very much your remarkably quirky and amusing idea of forcing Firefox to use an .html file in order to teach it a lesson, and I will certainly give it a try.

But for the life of me, I cannot understand how such a simple endeavour -- importing a barebones .html file -- can get Firefox into such a twist of its metaphorical knickers.

Sorry. I got so wrapped up in my thought's about the topic that it escaped my mind that you said "Opera". There's more than one way to skin a cat.

A big advantage to the bookmarks.html format is that Firefox will "append" existing bookmarks, rather that "replace" then as with the JSON backup format.

With 15,000 bookmarks, my new idea is to split that file to somewhat equal parts, of say 3000 bookmarks each so that you have 5 resulting files to be Imported. I don't know that the limit is in Firefox these days; I was having problems with only 3000 bookmarks "way back when" I was messing with this.

In the my experience, as long as a bookmarks.html has the proper "Netscape" header and a proper "break"is made in the formatting sequence, Firefox will import it and not lose a single bookmark. And subsequent portions of one big file, with the "Netscape" header added to each portion, will be accepted by Firefox, too. There is no "footer" or "ending" to a bookmarks.html file. And the order that I Imported the bookmarks.html files was reflected inside Firefox with the correct order and I don;t recall losing any bookmarks. But I was "only" working with like 3000 bookmarks as I recall; with the "splitting" and then importing of two separate file - so YMMV.

As far as "reading" where to make the "cut": I hope Opera follows suit with this "convention". And it ain't easy doing < and > signs in HTML code in this forum software, so I may screw it up. And I can't do leading spaces for line-offsets either, so I'll fill with italic letters and periods for the off-set that I see. Depending upon upon the editor you use, you may see more or less "offsets" with "folders". I am currently viewing a bookmarks.html file that I opened in Firefox (as a "webpage") and viewing Page Source in Firefox.

<DL&gt<p&gt is the beginning of the "nitty, gritty" part

and...<DL> <H3 > is used to start a folder "group" of bookmarks and closed with just a </H3> on the same line, And from Firefox you would see ADD_DATE and LAST_MODIFIED, each with the Epoch date (which you will see for each bookmark, too) if Opera did that, too. And Firefox uses ICON_URI= for retrieving the Favicon URL so it can convert it to "data:image/png;base64" when a new bookmarks is used for the first time.

<DT> is the start of each bookmark and is closed with </DT>

Be careful where you "split" or make a "cut" so that you don't lose one or more bookmarks ("more" if you misjudge the offset and ending tag in the middle of a folder). And when you are saving the individual "split" files, I wouldn't use bookmarks1.htm, bookmarks2.htm and such to keep them in order for importing. Firefox will accept bookmark.html (without the "s") as Exported from IE, but I doubt anything else as far as the file name - YMMV.

a closing tag of <DL><p> isn't needed at the "split" as I recall

And this needs to be at the top of any "section" - I believe that is how Firefox determines that the file to be "imported" is a "bookmarks.html" file and not just "any old" HTML file. <!DOCTYPE NETSCAPE-Bookmark-file-1&gt

I hope this works for you. I has been a long time since I have this, like maybe as long ago as 10 years, and I hope recollection of the processes I used was clear.

Edmeister,

I'm happy to report I've been able to fool Firefox thanks to your trick. This works:

Create a new Profile and with Firefox closed, delete the places.sqlite file and whatever json backup files may exist in the /bookmarkbackups/ folder. Then place that bookmarks.html file. Then start Firefox and see what happens. I figure that when you launch Firefox and it discovers that the places.sqlite file is missing, that it will "look" to the /bookmarbackups/ folder for the latest json backup file; when one isn't found, Firefox should use that bookmarks.html file of yours. As it does on "first-run" upon installation or when a new Profile is created.

15 000 bookmarks re-connected without a flinch, stupid Unresponsive Scripts or other annoyances. First launch of Firefox after I slipped in the bookmarks.html file was just a tad longer than usual (FF picking up its marbles, I suppose), but everything ran fine from there.

I was able to read my favorites, save new ones, and even generate a new file by using Export bookmarks to HTML (did not try to import it back somewhere, though).

Most probably, FF uses directly this unorthodox favorites file, without sucking its contents into its own places.sqlite, because the latter is exactly the same size than when the profile was created.

It's funny to consider that this "empty" and virgin places.sqlite file is 10,2 Mb, whereas my "huge", at least 7-years old, 15 000 bookmarks .html file is only 2,5 Mb.

There's at least one drawback to that trick, however : the automatic backup feature does not work. Import and backup / Restore does not list any backup dates after FF has been closed once, and the bookmarkbackups folder remains empty.

Thank you very much for the other, detailed explanation in your further post ; I will address that a bit later.

Well, folks, this is embarrassing. The problem seems to have cured itself.

Let me describe my last bit of detective work, because I'm still baffled by the issue and am still looking for explanations. Encouraged by The-Edmeister's reminder of how easy it is to create a new profile for testing purposes, I did just that, to experiment once more with the Firefox-supported way of doing things, i.e. importing bookmarks from an .html file (as opposed to forcing it to use the .html file as its bookmarks repository by deleting places.sqlite).

• Create new profile.
• Show all bookmarks / Import and backup / Import bookmarks from HTML / bookmarks.html.
• Firefox goes into Not responding mode.
• A short while later, the Unresponsive Script warning pops up.
• Click Continue, but before that, tick Don't ask me again (that's what I had never done before, in my multiple attempts).
• Roughly 1 minute later, the 15 000 bookmarks are imported. Done !

So, maybe something is corrupted in my main profile (despite the fact that it's only a few days old) ? Let's see.

• Open main profile.
• Show all bookmarks (those that have been re-connected by The-Edmeister's bootleg method).
• Delete the top folder.
• Firefox goes into Not responding mode.
• A short while later, the Unresponsive Script warning pops up.
• Don't ask me again, Continue.
• Deleted, quick and nice.

And now, the acid test :

• Stay in main profile.
• Import bookmarks from HTML / bookmarks.html.
• I don't remember whether Firefox went into Not responding.
• No Unresponsive Script warning whatsoever.
• Roughly 1 minute later, the 15 000 bookmarks are imported.

Infuriating, no ? As far as I can tell, nothing changed in my configuration between now and the multiple failed attempts that motivated my question...

Feature request : a progress bar would be nice for import / export of bookmarks, but what's absolutely lacking is a confirmation message such as "xxx bookmarks were successfully imported".

Thanks, anyway, for having already greatly helped me to understand how Firefox works !

I'm glad that you got it solved so quickly with the new Profile and dropping that bookmarks.html file in there.

iirc, a fresh places.sqlite file starts out at 10Mb per what I have seen cor-el post in this forum.

Bookmarks.html is now considered a legacy file, and I think the the code that reads and writes that format was specifically kept around to retain the ability to import and export for the purposes of interchangeability with other browsers floating around out there - or maybe that someone was too lazy to remove it? Honestly though, I don't think it will be in Firefox too much longer; probably will disappear with Servo, if not sooner.

As far as a progress bar, you can provide feedback to Mozilla here and request that feature. https://input.mozilla.org/en-US/feedback

I hope the html format will remain. Being able to back up bookmarks across browsers is, indeed, one of the main reasons I'm so fixated on it.

Unfortunately, browsers are not reliable tools, to put it bluntly. There are too few of them around, and you can't trust one or the other to consistently serve your needs in the future. They are all free, so the strategies needed to support them financially may not be in the best interest of the user.

Incidentally, I don't consider this unresponsive script issue solved, although I'm very grateful for the workaround you provided and all the formative help you and others contributed.

When I tried to import my html file under another Windows account, Firefox hanged again. It finally managed to import the bookmarks, but there's obviously a random element there. I don't have the slightest idea whether I'll be able to build a robust backup strategy for those bookmarks in the future, and that is unacceptable in my view.

I imported again repeatedly this file into Opera, and it succeeds all the time, poof ! one second, faultlessly, so technically this shows that it's doable.

Unless html is a not-so-standard standard, and there are variations between implementations which could lead to incompatibilities, but I'm not aware of such a thing.

I will sure use your feedback link -- I was not aware of it !

Firefox seems to using JavaScript code to import an HTML file and that is always slower than using C++ code and if this JavaScript code runs into the check for hangs (max_chrome_script_run_time) then you get a slow script alert. Importing a large amount of bookmarks can take considerable time.

cor-el said

Firefox seems to using JavaScript code to import an HTML file and that is always slower than using C++ code and if this JavaScript code runs into the check for hangs (max_chrome_script_run_time) then you get a slow script alert. Importing a large amount of bookmarks can take considerable time.

I understand. I did notice a considerable difference between importing in Opera and Firefox when all went well : roughly 1 second and 1 minute for the same file.

But that's not really a problem. One minute for a routine maintenance operation is perfectly tolerable. The problem (and insecurity) comes from Firefox freezing at random, and you don't know why, or how to avoid it.