Closed Bug 334408 Opened 19 years ago Closed 18 years ago

Bookmark import/export should get/set last character set as annotation and use it when loading a page

Categories

(Firefox :: Bookmarks & History, defect, P2)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mozilla, Assigned: hello)

References

Details

Attachments

(1 file, 5 obsolete files)

Blocks: 334409
Blocks: 334410
I don't know which of these you meant to file but I'll dupe them to this one.
or not. Joe... did you mean to file 3 bugs (334408, 334409, 334410) that are all almost exactly the same?
Basically, the work described here will define the annotation to use, and then bug 334409 and bug 334410 describe two different conditions in which that annotation needs to be updated.
Priority: -- → P3
Summary: Bookmark import should preserve last character set as annotation and use it when loading a page → Bookmark import/export should get/set last character set as annotation and use it when loading a page
Target Milestone: Firefox 2 beta1 → Firefox 3 alpha2
Version: 2.0 Branch → Trunk
Does "use it when loading a page" encompass implementing nsICharsetResolver (bug 284660, bug 101995), or do we need another bug for that?
Assignee: brettw → nobody
Priority: P3 → --
Target Milestone: Firefox 3 alpha2 → ---
Attached patch wip patch (obsolete) — Splinter Review
Do we want to land this before turning bookmarks on? I'm not sure whether (a) the anno string is at all appropriate, or (b) it should be a page anno vs an item anno. But, heh, here's a start. Note: only applies cleanly on top of "fix v5" patch from bug 376253.
Assignee: nobody → thunder
Status: NEW → ASSIGNED
Attachment #264984 - Flags: review?(mano)
Depends on: 317472
Comment on attachment 264984 [details] [diff] [review] wip patch In places we want to this to be set as a page-annotation, see also bug 317472. I don't think we should block places-bookmarks for this FWIW.
Attachment #264984 - Flags: review?(mano) → review-
No longer depends on: 317472
Flags: blocking-firefox3?
Flags: blocking-firefox3? → blocking-firefox3-
Priority: -- → P2
Whiteboard: [wanted-firefox3]
Attached patch patch v1 (obsolete) — Splinter Review
Fixes the anno string to match the one in bug 317472.
Attachment #264984 - Attachment is obsolete: true
Attachment #271155 - Flags: review?(mano)
hey dan, I think something is wrong with that patch.
Attached patch patch v1 (really) (obsolete) — Splinter Review
I had a long battle with hg for windows (which I lost) today, trying to make it use 8 lines of context for diffs. I guess I broke my patch during that time... sigh. Thanks Seth :)
Attachment #271155 - Attachment is obsolete: true
Attachment #271177 - Flags: review?(mano)
Attachment #271155 - Flags: review?(mano)
This should be set as a uri annotation, not item annotation (if the annotation is not set already).
Comment on attachment 271177 [details] [diff] [review] patch v1 (really) For the same reason i minus ed the former ;)
Attachment #271177 - Flags: review?(mano) → review-
Attached patch patch v2 (obsolete) — Splinter Review
That's... embarrassing. Sorry. Here's a new patch, I made these changes: $ hg diff diff -r c2674415e051 browser/components/places/src/nsPlacesImportExportService.cpp --- a/browser/components/places/src/nsPlacesImportExportService.cpp Thu Jul 05 22:25:18 2007 -0700 +++ b/browser/components/places/src/nsPlacesImportExportService.cpp Fri Jul 06 13:45:08 2007 -0700 @@ -965,9 +965,11 @@ BookmarkContentSink::HandleLinkBegin(con // import last charset if (!lastCharset.IsEmpty()) { - mAnnotationService->SetItemAnnotationString(frame.mPreviousId, LAST_CHARSET_ANNO, - lastCharset, 0, - nsIAnnotationService::EXPIRE_NEVER); + nsCOMPtr<nsIURI> hrefObject; + if (NS_SUCCEEDED(NS_NewURI(getter_AddRefs(hrefObject), href))) + mAnnotationService->SetPageAnnotationString(hrefObject, LAST_CHARSET_ANNO, + lastCharset, 0, + nsIAnnotationService::EXPIRE_NEVER); } } @@ -1922,12 +1924,12 @@ nsPlacesImportExportService::WriteItem(n // last charset PRBool hasLastCharset = PR_FALSE; - rv = mAnnotationService->ItemHasAnnotation(itemId, LAST_CHARSET_ANNO, + rv = mAnnotationService->PageHasAnnotation(pageURI, LAST_CHARSET_ANNO, &hasLastCharset); NS_ENSURE_SUCCESS(rv, rv); if (hasLastCharset) { nsAutoString lastCharset; - rv = mAnnotationService->GetItemAnnotationString(itemId, LAST_CHARSET_ANNO, + rv = mAnnotationService->GetPageAnnotationString(pageURI, LAST_CHARSET_ANNO, lastCharset); NS_ENSURE_SUCCESS(rv, rv); rv = aOutput->Write(kLastCharsetAttribute, sizeof(kLastCharsetAttribute)-1, &dummy);
Attachment #271177 - Attachment is obsolete: true
Attachment #271265 - Flags: review?(mano)
Comment on attachment 271265 [details] [diff] [review] patch v2 >+ if (!lastCharset.IsEmpty()) { >+ nsCOMPtr<nsIURI> hrefObject; >+ if (NS_SUCCEEDED(NS_NewURI(getter_AddRefs(hrefObject), href))) You have it in frame.mPreviousLink. >+ mAnnotationService->SetPageAnnotationString(hrefObject, LAST_CHARSET_ANNO, I think we should only do this if the annotation is not already set.
Attachment #271265 - Flags: review?(mano) → review-
(In reply to comment #13) > (From update of attachment 271265 [details] [diff] [review]) > > >+ if (!lastCharset.IsEmpty()) { > >+ nsCOMPtr<nsIURI> hrefObject; > >+ if (NS_SUCCEEDED(NS_NewURI(getter_AddRefs(hrefObject), href))) > > You have it in frame.mPreviousLink. Indeed. I'll change the microsummary import to match as well, then. > >+ mAnnotationService->SetPageAnnotationString(hrefObject, LAST_CHARSET_ANNO, > > I think we should only do this if the annotation is not already set. Can you explain why? It makes more sense to me to have the imported value take precedence.
Attached patch patch v3 (obsolete) — Splinter Review
Uses frame.mPreviousLink instead of making a new uri object.
Attachment #271265 - Attachment is obsolete: true
If I've visited a page, then imported my ancient bookmarks file which happened to have that page in too, the already-set character-set should take precedence IMO. I think we better consider generated meta data like this as useful only if we don't have something better.
Comment on attachment 271407 [details] [diff] [review] patch v3 r=mano otherwise.
Attachment #271407 - Flags: review+
Attached patch final patchSplinter Review
Here it is with the anno check. I think you're right. At least, now that we're appending bookmarks instead of merging them in. I'll commit tomorrow when I'll be awake to watch tinderbox...
Attachment #271407 - Attachment is obsolete: true
Checked in: Checking in browser/components/places/src/nsPlacesImportExportService.cpp; /cvsroot/mozilla/browser/components/places/src/nsPlacesImportExportService.cpp,v <-- nsPlacesImportExportService.cpp new revision: 1.25; previous revision: 1.24 done I forgot to update the tests for the item -> page & anno name changes, so I had to commit those twice. Last commit was: Checking in browser/components/places/tests/unit/test_bookmarks_html.js; /cvsroot/mozilla/browser/components/places/tests/unit/test_bookmarks_html.js,v <-- test_bookmarks_html.js new revision: 1.10; previous revision: 1.9 done Marking as fixed.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Is there a user method of verifying this bug? Also should this bug be flagged in-testsuite+
I used the sqlite database browser (http://sqlitebrowser.sourceforge.net/) to open up places.sqlite and check its contents. I don't think there's an easier way to check it, since the annotation is not currently used to choose the encoding.
Dan, are there unit test case(s) running regularly that confirm it is fixed? It be fine with that as verification.
(In reply to comment #21) > I don't think there's an easier way to check it, since the annotation is not > currently used to choose the encoding. So the answer to comment 4 was "yes, we need another bug about using it, the 'use it when loading a page' in the summary is just a tease"?
ok, verified per unit tests also added in-testsuite+
Status: RESOLVED → VERIFIED
Flags: in-testsuite+
Flags: wanted-firefox3+
Whiteboard: [wanted-firefox3]
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: