Closed Bug 422291 Opened 17 years ago Closed 17 years ago

Smart Bookmarks/Place: default behavior changed

Categories

(Firefox :: Bookmarks & History, defect)

defect
Not set
normal

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: jonnan.west, Assigned: ondrej)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4 The "Recent Tags" Smart bookmark "place:folder=4&group=3&sort=12&applyOptionsToContainers=1&maxResults=10&queryType=1" no longer returns URLs in the form of a tag folder, nor does the (Manually created) tag sorting folder "place:folder=4&group=3&sort=1&applyOptionsToContainers=1&maxResults=100&queryType=1" Reproducible: Always Steps to Reproduce: Simply click on the smart Bookmarks folder on the bookmarks toolbar and highlight Recent Tags; Actual Results: This now returns a single website for each results, with no obvious information showing any correspondence between the tag folders originally returned, and the single website returned now. Expected Results: in Beta Three, this returned (and the manually created folder) folders for each of the tags that contained links to the websites that met the criteria. This may be an intentional/expected change, but I'm not seeing it documented as such - the new returned values are much less useful than the tag folders format IMO.
groupings does not exists anymore and that query is wrong (should have been replaced really...)
(In reply to comment #0) "place:folder=4&group=3&sort=12&applyOptionsToContainers=1&maxResults=10&queryType=1" > no longer returns URLs in the form of a tag folder, This is not the original URL, the original looks like this: "place:folder=4&group=3&sort=12&applyOptionsToContainers=1&maxResults=10&queryType=1" It contains same parameters but in different order. That is why it has not been replaced with the new correct version. > nor does the (Manually created) tag sorting folder > "place:folder=4&group=3&sort=1&applyOptionsToContainers=1&maxResults=100&queryType=1" As Marco said, grouping has gone with bug 385245, the correct new version of this is: place:type=6&sort=1&maxResults=100 The reason why you see something strange is that we ignore parameter that we do not know, so group is ignored and rest of the query gets interpreted in an other way. I will use this bug to fix documentation: http://developer.mozilla.org/en/docs/Places:PlaceURIs http://developer.mozilla.org/en/docs/nsINavHistoryQueryOptions
Assignee: nobody → ondrej
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
(In reply to comment #2) > (In reply to comment #0) > This is not the original URL, the original looks like this: OOPS, this is the original: "place:folder=4&group=3&queryType=1&applyOptionsToContainers=1&sort=12&maxResults=10";
Status: NEW → ASSIGNED
Ondrej, does this change effects beta users of Firefox 3 when they will run a final version later? Do they have to recreate their places.sqlite to get this functionality? I ask because of bug 426340.
Version: unspecified → Trunk
In general the answer is no - there was a conversion added for beta users. However, there was a short period of time (I guess about one day) when nightly users could get to strange situation, because the new uri has changed for second time without the update code. This was done intentionally in order not to pollute the updating code. But if there were problems, they would have probably be already escalated.
Ok, sounds good. Then beta users will not be affected. Thanks!
All the docs in this bug (and some others I checked as well) have been updated. Ondrej, if you made the updates you reference in the comments here, please mark this fixed. Otherwise, mark WFM.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
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.