354494 - bookmarks_history.sqlite is not being used after auto-upgrade to Gecko/20060926 Minefield/3.0a1

Status: RESOLVED INVALID

(Firefox :: Bookmarks & History, defect)

Description

[mekanik2600]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060926 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060926 Minefield/3.0a1

After the auto-update was completed and installed the new firefox.exe binary no longer uses "bookmarks_history.sqlite" for the browser history (it is back to the old history storage "history.dat").  The file is still present and permissions have not changed.  I can use sqlite to open up the database and view the rows/tables with no problems.  firefox.exe seems to have gone back in time and is now using the "history.dat" file and storage method again.

[Header from history.dat]
-------------------------
// <!-- <mdb:mork:z v="1.4"/> -->
< <(a=c)> // (f=iso-8859-1)
  (8A=Typed)(8B=GeckoFlags)(8C=LastPageVisited)(8D=ByteOrder)
  (80=ns:history:db:row:scope:history:all)
  (81=ns:history:db:table:kind:history)(82=URL)(83=Referrer)
  (84=LastVisitDate)(85=FirstVisitDate)(86=VisitCount)(87=Name)
  (88=Hostname)(89=Hidden)>

[Update History Information]
----------------------------
Minefield 3.0a1 (2006092604)
Security Update
Installed on:  Tuesday, September 26, 2006 <time>
Status:        The Update was successfully installed

[Build Identifier]
------------------
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/2006092604 Minefield/3.0a1

[About:BuildConfig]
-------------------
Build platform
target
i586-pc-msvc

Build tools
Compiler 	Version 	Compiler flags
$(CYGWIN_WRAPPER) cl 	14.00.50727 	-TC -nologo -W3 -Gy -Fd$(PDBFILE)
$(CYGWIN_WRAPPER) cl 	14.00.50727 	-GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fd$(PDBFILE)

Configure arguments
--enable-application=browser --enable-update-channel=nightly --enable-optimize --disable-debug --disable-tests --enable-static --disable-shared --enable-svg --enable-canvas --enable-default-toolkit=cairo-windows --enable-update-packaging

Reproducible: Always

Steps to Reproduce:
1. open firefix
2. try to visit site stored in history
3. history does not show site to be store in history



Expected Results:  
stored sites should be in history

Comment 1

[Dave Townsend [:mossop]]

As detailed at http://developer.mozilla.org/devnews/index.php/2006/09/20/places-to-be-disabled-on-trunk-nightlies/ places is disabled on trunk builds for the time being.

Comment 2

[mekanik2600]

(In reply to comment #1)
> As detailed at
> http://developer.mozilla.org/devnews/index.php/2006/09/20/places-to-be-disabled-on-trunk-nightlies/
> places is disabled on trunk builds for the time being.
> 

So, this include the "bookmarks_history.sqlite" file used for history along with the bookmarks?  I can understand the bookmarks, but the history is a totally different component, yet they use the same storage method.  So, what is the workaround?  I can export table content from "bookmarks_history.sqlite", but how do you import that into the history.dat format?

Comment 3

[mekanik2600]

What about live-bookmarks?  By not using the "bookmarks_history.sqlite", this also breaks them.  What is the workaround for that?

Regards

Comment 4

[Dave Townsend [:mossop]]

I don't know if there is a workaround to either (I suspect not). History is affected because the places component is all about moving bookmarks and history into a new form.

I suggest as a workaround you download an old nightly from before places was disabled and not install a new nightly until places is turned back on.

Nightlies are for testing purposes, you should not expect them to work all the time and any profile data you use in a nightly is at some risk of being lost.

Comment 5

[mekanik2600]

(In reply to comment #4)
> I don't know if there is a workaround to either (I suspect not). History is
> affected because the places component is all about moving bookmarks and history
> into a new form.

[mekanik]
Which is what my conclusion was also (since the storage has moved back to history.dat).

> I suggest as a workaround you download an old nightly from before places was
> disabled and not install a new nightly until places is turned back on.

[mekanik]
That was my thought, but wanted to see if there was any possible workaround for importing or formatting to the history.dat format.

> Nightlies are for testing purposes, you should not expect them to work all the
> time and any profile data you use in a nightly is at some risk of being lost.
> 

[mekanik]
Fully agree and understandable.

Thanks for the info.  Regards,
mekanik