Closed Bug 1446672 Opened 2 years ago Closed 2 years ago
Can't see bookmarks after updating to 60 beta
Bug 1446672 - Correctly handle insertion of L10n strings into Places' built-in virtual queries for all bookmarks/left-pane.
59 bytes, text/x-review-board-request
3.20 KB, patch
|Details | Diff | Splinter Review|
342.05 KB, image/png
312.07 KB, image/png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180315232954 Steps to reproduce: After updating my 2 PCs to Firefox 60 beta I can't see my bookmarks in the sidebar or the library. If I put some text in the search box it shows the results so it seems that my bookmarks are there, but I can't browse it. Screenshot: https://i.imgur.com/Pb6dcBC.png Windows 10 60 bits
Please can you try this: - Close the library & sidebar - Restart Firefox - Go to the app menu, then developer tools followed by browser console (not Web console) - with that open, either open the sidebar or the library - see if any messages appear and copy & paste them here. Could you also go to Help - Troubleshooting Information and goto the Places Integrity section and hit Verify. Again, copy and paste output here, then restart Firefox and see if that has helped.
(In reply to Mark Banner (:standard8) (afk until 19 Mar) from comment #1) > - with that open, either open the sidebar or the library > - see if any messages appear and copy & paste them here. No messages are generated by opening the sidebar but opening the library generates this error: TypeError: PlacesUtils.asContainer(...) is null[Més informació] places.js:125:9 selectLeftPaneContainerByHierarchy chrome://browser/content/places/places.js:125:9 PO_init chrome://browser/content/places/places.js:143:5 onload chrome://browser/content/places/places.xul:1:1 > Could you also go to Help - Troubleshooting Information and goto the Places > Integrity section and hit Verify. Again, copy and paste output here, then > restart Firefox and see if that has helped. It doesn't solve the problem. This is the output (I lost the first time execution output, this is the 2n one): > Task: checkIntegrity + The database is sane > Task: invalidateCaches + The caches have been invalidated > Task: checkCoherence + The database is coherent > Task: expire + Database cleaned up > Task: vacuum + Initial database size is 51200KiB + The database has been vacuumed + Final database size is 51200KiB > Task: stats + Places.sqlite size is 51200KiB + Favicons.sqlite size is 28416KiB + pragma_user_version is 43 + pragma_page_size is 32768 + pragma_cache_size is -2048 + pragma_journal_mode is wal + pragma_synchronous is 1 + History can store a maximum of 155181 unique pages + Table moz_places has 106813 records + Table moz_historyvisits has 201488 records + Table moz_inputhistory has 448 records + Table moz_hosts has 6405 records + Table moz_bookmarks has 2828 records + Table moz_keywords has 7 records + Table sqlite_sequence has 1 records + Table moz_anno_attributes has 12 records + Table moz_annos has 288 records + Table moz_items_annos has 139 records + Table sqlite_stat1 has 19 records + Table moz_bookmarks_deleted has 0 records + Index sqlite_autoindex_moz_inputhistory_1 + Index sqlite_autoindex_moz_hosts_1 + Index sqlite_autoindex_moz_keywords_1 + Index sqlite_autoindex_moz_anno_attributes_1 + Index sqlite_autoindex_moz_bookmarks_deleted_1 + Index moz_places_hostindex + Index moz_places_visitcount + Index moz_places_frecencyindex + Index moz_places_lastvisitdateindex + Index moz_historyvisits_placedateindex + Index moz_historyvisits_fromindex + Index moz_historyvisits_dateindex + Index moz_bookmarks_itemindex + Index moz_bookmarks_parentindex + Index moz_bookmarks_itemlastmodifiedindex + Index moz_places_url_hashindex + Index moz_places_guid_uniqueindex + Index moz_bookmarks_guid_uniqueindex + Index moz_annos_placeattributeindex + Index moz_items_annos_itemattributeindex + Index moz_keywords_placepostdata_uniqueindex + Index moz_bookmarks_dateaddedindex > Task: _refreshUI
Thank you for the response. I've just tried this on the Catalan Firefox 60b4 build and I can reproduce it with my normal test profiles. Testing the same builds on en-US, fr, gn all seem to work fine. I'm looking into the reasons why this might be.
Assignee: nobody → standard8
Severity: normal → critical
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P1
Tracking request: Significant regression in bookmarks functionality for at least users of Catalan (ca), could affect other locales, currently investigating.
This affects any locale that has a single-quote in one of their '*FolderTitle*' strings in places.properties: https://dxr.mozilla.org/l10n-mozilla-beta/search?q=regexp%3A%22FolderTitle.*%27%22+file%3Aplaces.properties&redirect=false Currently, an, ca, cak, lg and pbb.
Comment on attachment 8960138 [details] Bug 1446672 - Correctly handle insertion of L10n strings into Places' built-in virtual queries for all bookmarks/left-pane. https://reviewboard.mozilla.org/r/228938/#review234620 Thank you for quick action on this. ::: toolkit/components/places/nsNavHistory.cpp:1987 (Diff revision 1) > - "(null, 'place:folder=BOOKMARKS_MENU', '%s', null, null, null, " > + "(null, 'place:folder=BOOKMARKS_MENU', :BookmarksMenuFolderTitle, null, null, null, " > "null, null, 0, 0, null, null, null, null, 'menu_______v', null), " > - "(null, 'place:folder=UNFILED_BOOKMARKS', '%s', null, null, null, " > + "(null, 'place:folder=UNFILED_BOOKMARKS', :OtherBookmarksFolderTitle, null, null, null, " > "null, null, 0, 0, null, null, null, null, 'unfiled___v', null) " > " %s " > ")", At this point you can probably drop nsPrintfCString and sum strings. mQueryString = NS_LITERAL_CSTRING("...") + mobileString + NS_LITERAL_CSTRING(")");
Attachment #8960138 - Flags: review?(mak77) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/a270d805647c Correctly handle insertion of L10n strings into Places' built-in virtual queries for all bookmarks/left-pane. r=mak
QE Verify: Should verify on the locales in comment 5 and check that en-US or another locale is still fine. Steps: 1) Start up Firefox, select Bookmarks -> Show All Bookmarks (or any other entry point), check that the Menu/Toolbar/Other folders are displayed correctly under All Bookmarks. 2) Connecting a sync account (or set browser.bookmarks.showMobileBookmarks to true), then the Mobile folder should also be displayed correctly as well in all the locales.
Comment on attachment 8960155 [details] [diff] [review] Beta patch Patch for beta - removed the left-pane parts which don't apply there. Approval Request Comment [Feature/Bug causing the regression]: Bug 1423896 [User impact if declined]: Users of various locales (an, ca, cak, lg and pbb) won't be able to use bookmarks / various bookmark dialogs. [Is this code covered by automated tests?]: The code is covered, but can't test the actual issue due to the fact we don't have proper locale testing. [Has the fix been verified in Nightly?]: Not yet. [Needs manual test from QE? If yes, steps to reproduce]: Yes, see comment 11 [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: No [Why is the change risky/not risky?]: Uses existing methods/style of code to correctly insert the strings into the queries. [String changes made/needed]: None
Comment on attachment 8960155 [details] [diff] [review] Beta patch fix bookmarks in some locales, beta60+
Attachment #8960155 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Hi, I have just reproduced the issue and verified that the fix works. I have reproduced it on Fx 59.0b12 with ca locale and tested it with Beta 60.0b5 and Nightly 61.0a1 with "an", "ca" and "cak" locales and also en-US to see if the fix caused any regressions to the unaffected locales. Nightly 61.0a1-cak didn't seem fixed so I uploaded a print screen with the issue. I'm gonna leave the flag for 61 in place. The fix seems to have done it's job but I couldn't find the "lg" and "pbb" locales specified in Comment #5 to also test on those. Where can I find them?
(In reply to Alexandru Simonca, QA (:asimonca) from comment #17) > I have just reproduced the issue and verified that the fix works. I have > reproduced it on Fx 59.0b12 with ca locale and tested it with Beta 60.0b5 > and Nightly 61.0a1 with "an", "ca" and "cak" locales and also en-US to see > if the fix caused any regressions to the unaffected locales. Nightly > 61.0a1-cak didn't seem fixed so I uploaded a print screen with the issue. > I'm gonna leave the flag for 61 in place. Hmm, I just tried the 20th March cak build from https://ftp.mozilla.org/pub/firefox/nightly/2018/03/2018-03-20-10-01-22-mozilla-central-l10n/ and it seemed fine. Could you retry? I wonder if it hadn't regenerated at the time you tested it. > The fix seems to have done it's job but I couldn't find the "lg" and "pbb" > locales specified in Comment #5 to also test on those. Where can I find them? It looks like we're not actually shipping these locales at the moment, so we don't need to check them (I extracted that list from the l10n directories, rather than the shipped-locales information): https://dxr.mozilla.org/mozilla-beta/rev/e8887d50d037e3fc4c74142e95ef529b1e6025e2/browser/locales/shipped-locales
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 I opened the link that you left me in the previous comment and did the same testing. Same result. You can see the issue in the attachment.
(In reply to Alexandru Simonca, QA (:asimonca) from comment #19) > I opened the link that you left me in the previous comment and did the same > testing. Same result. You can see the issue in the attachment. The build id there is from yesterday's build before the fix landed.
Verified fixed for the "cak" locale using Nightly 61.0a1 (id: 20180321040527) on Windows 10 x64.
You need to log in before you can comment on or make changes to this bug.