Extend `Bookmarks.fetch` to allow a `parentGuid` without an `index`
Categories
(Toolkit :: Places, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox81 | --- | fixed |
People
(Reporter: lina, Assigned: mkaply)
Details
Attachments
(1 file, 1 obsolete file)
Updated•8 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Shouldn't this just be removing this line:
All of the queries in the file already take parentGuid into account when doing their queries.
Comment 2•4 years ago
|
||
(In reply to Mike Kaply [:mkaply] from comment #1)
Shouldn't this just be removing this line:
Yes, with a test checking that the default value works (likely it needs a "defaultValue: this.DEFAULT_INDEX," instead of "requiredIf")
Assignee | ||
Comment 3•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
Posted before your comment. I'll make the additional changes.
Comment 5•4 years ago
•
|
||
also, I'm not sure it's just going to work because it seems comment 0 is requesting a behavior change, so fetching without an index fetches all the children... currently with parent and index it only fetches one... As I said I can't check atm due to lack of time left (sorry).
we have await fetchBookmarkByPosition(fetchInfo, options); this seems to require the addition of a fetchBookmarksByParent similar to fetchBookmarksByURL
Assignee | ||
Comment 6•4 years ago
|
||
Yeah, this is way more complicated then it looks. It looks like you can't combine various fetch items at all. So if you specify a GUIDPrefix, you can't use Tags for instance.
So my use case - specifying a GUID prefix and a parentGUID wouldn't even work.
But Lina's use case is pretty straightforward, so I can still do a patch for that.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 7•4 years ago
|
||
Comment 9•4 years ago
|
||
bugherder |
Description
•