329806 - nsStorageFormHistory needs to recognize endianness marker when importing old mork db

Status: RESOLVED FIXED

(Toolkit :: Form Manager, defect)

Description

[Mark Mentovai]

In bug 328982, I added endianness markers to the formhistory.dat mork db.  This file is being replaced, effective 1.8.1, with a sqlite db implemented in nsStorageFormHistory.  There is an importer that uses morkreader to import formhistory.dat.  It needs to recognize the new endianness marker.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/components/satchel/src/nsStorageFormHistory.cpp&rev=1.6&mark=569#557

The importer should use the same heuristics as nsFormHistory to decide what to do when no endianness marker is present.

Comment 1

[Mark Mentovai]

Attachment: Endian-dependent formhistory import

This mostly follows nsMorkHistoryImporter.

Comment 2

[Mark Mentovai]

Attachment: nsMorkHistoryImporter fixes

Changes:
- Mask out high-order 8 bytes when right shifting because the behavior of the
  sign bit is undefined
- Add a pair of casts to avoid warnings about enum mismatches (the generated
  header puts each item in its own enum)
- Don't attempt to read byte order when not set in history.db (as in upgrades
  from 1.0.x to 2.0)
- Don't byte-swap when byte order is set to something unrecognizable

Comment 3

[Mark Mentovai]

Both patches have been checked in on the trunk.

Comment 4

[Brian Ryner (not reading)]

Comment on attachment 214472 [details] [diff] [review]
nsMorkHistoryImporter fixes 

fwiw all checkins to places code (browser/components/places/ and nsStorageFormHistory) should be committed on the branch at the same time as the trunk.

Comment 5

[Mark Mentovai]

OK, on 1.8 now.  What ever happened to the idea of automatically syncing the trunk and branch in toolkit and browser?