Open Bug 1541063 Opened 5 years ago Updated 8 months ago

Tags gets duplicated inside the Library when attempting to change the Location

Categories

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

63 Branch
defect

Tracking

()

Tracking Status
firefox-esr60 --- unaffected
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix

People

(Reporter: asoncutean, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(1 file, 4 obsolete files)

Attached image screencast issue.gif

[Affected versions]:

  • 66.0.2
  • 67.0b7
  • 68.0a1 (2019-04-01)

[Affected platforms]:

  • Win 10 x64
  • Mac OS 10.10
  • Ubuntu 18.04 x64

[Steps to reproduce]:

  1. Bookmark any site via Star icon, given several tags (eg. a, b, c )
  2. Go to Library (Ctrl+Shift+B)
  3. Open the tags dropdown
  4. Inside Location paste another link
  5. Click one of the tag

[Expected result]:

  • The respective tag is now unselected.

[Actual result]:

  • Tags are duplicated.

[Regression range]:

  • I will determine one asap.

[Additional Notes]:

  • I can reproduce this intermittent, sometimes with other workarounds. I will investigate more on this matter for better conclusions.
  • Collapsing the dropdown fixes the problem.

STR2:

  1. Start Firefox with new profile
  2. Click on Star Icon
  3. Expand Tags list view
  4. Type a,b in Tags input field (do not press enter key)
  5. Click on Name input field

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b89b6c6da94b95abf74a79797f58542acb3e55c1&tochange=d60086281de9b5d9fe804e76c2c1721850b0f730

Regressed by:
d60086281de9 Marco Bonardo — Bug 1452067 - Move AllTags to an async method in the bookmarking API. r=Standard8

Regressed by: 1452067
Version: Trunk → 63 Branch
Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(mak77)

I'll have a look at this.

Assignee: nobody → mak77
Status: NEW → ASSIGNED
Flags: needinfo?(mak77)
Priority: -- → P2

Anyway, I suspect the problem is that when you click on the tag in the selector, you blur the location field, and that causes the url change that notifies an onItemChanged that invokes the now async _rebuildTagsSelectorList. But at the same time you click on a tag, causing a racing tag change notification that races with the former one.

Marco and I have been discussing the patch and various issues that I'm still seeing. The issues seem to occur for me in this order:

  • Changing the URL, then selecting a tag without a blur in-between.
  • Mousedown invokes toggleItemCheckbox which starts to update the tags.
  • This calls into _updateTags and then _setTagsFromTagsInputField
  • _setTagsFromTagsInputField has an internal async function, setTags which is used to run the transactions to update the tags.
  • At the point that function is queued (probably in the batch handling), the blur is able to kick in for the location change.
  • onLocationFieldChange is called which updates the URL.
  • Only then does setTags get executed, and at this point it is dealing with the old URL rather than the new one.

hi mak, are you still working on this one?
thanks,
-Patricia

Yes, but higher priority stuff hit me and this ends up being a lot more complex than expected.

Flags: needinfo?(mak77)
Blocks: 1703004
Attachment #9056812 - Attachment is obsolete: true
Attachment #9081276 - Attachment is obsolete: true
Attachment #9083572 - Attachment is obsolete: true
Blocks: 1711726
Blocks: 1711117
Severity: normal → S3

Verify is this has been resolved by recent updates.

Flags: needinfo?(mak)

Most of the steps work correctly, what I can still reproduce:

  1. open the tags selector
  2. put a,b,c in the tags field and click on Location field
  3. edit the url, for example by adding a 2 at the end
  4. click on the first tag (it goes away)
  5. click again on the first tag

At this point all the tags are unchecked, even if "c" is still on that url

I think this is a bit less critical than the original issue, even if we should definitely investigate and fix it.

Assignee: mak → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(mak)
Priority: P2 → P3
Attachment #9222141 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: