Closed Bug 1484176 Opened Last year Closed Last year

Bookmarks sub-folder menupopup would not open when dragover onto the sub-folder. It became very difficult to open folder.

Categories

(Toolkit :: XUL Widgets, defect, P1)

63 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla64
Tracking Status
firefox-esr60 --- unaffected
firefox61 --- unaffected
firefox62 --- unaffected
firefox63 + verified
firefox64 --- verified

People

(Reporter: alice0775, Assigned: enndeakin)

References

Details

(Keywords: regression, Whiteboard: [fxsearch])

Attachments

(2 files)

[Tracking Requested - why for this release]: bookmarks menu drag and drop ux regression

This is regression since Nightly63.0a1.


When I drag a link and dragover onto bookmarkfolder_1, the sub-folder does not open.
STR
1. prepare bookmarks folder as follows

bookmark_1
bookmarkfolder_1
bookmark_2

2. Drag a link and move mouse pointer from top to bottom slowly


Actual Results:

It needs following steps and it is very annoying.
1. dragover between Bookmarkfoldr_1 and bookmark_2. so that dropindicator appears between them
2. and then move mouse pointer downward by 1px.
3. then the bookmarkfolder_1 will open as expected.

The target area is very narrower than firefox62 and earlier.
It seems that there is only 1-2pixel from bottom ​​the label.

Expected Results:
Bookmarks sub-folder menupopup should open when dragover onto the sub-folder


Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8da83fe09309320af068b5cebb97b876af2d427e&tochange=3af5036936c12d911a0a3de1ef86f692e7878486

Regressed by:
3af5036936c1	Emma Malysz — Bug 1454358, removes unneccessary implementation of ScrollBoxObject rr?enndeakin+6102 r=bz,enndeakin+6102


Emma Malysz,
your patch seems to cause the regression, could you please look into this?
Flags: needinfo?(emalysz)
Forwarding needinfo to Neil
Flags: needinfo?(emalysz) → needinfo?(enndeakin)
Priority: -- → P1
Whiteboard: [fxsearch]
Component: Bookmarks & History → XUL
Product: Firefox → Core
Tracked for 63 since it's a new regression.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Flags: needinfo?(enndeakin)
Attachment #9004252 - Flags: review?(dao+bmo)
Attachment #9004252 - Flags: review?(dao+bmo) → review+
Component: XUL → XUL Widgets
OS: Windows 10 → All
Product: Core → Toolkit
Hardware: x86_64 → All
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3988c607621f
somewhat revert the change from bug 1454358 for places menu.xml since the boxObject being used should be for the inner scrollbox, r=dao
https://hg.mozilla.org/mozilla-central/rev/3988c607621f
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Flags: qe-verify+
Dao, can we backport to 63 to fix the regression? Thanks
Flags: needinfo?(dao+bmo)
Yes, but let's get this verified in Nightly first.
Flags: needinfo?(dao+bmo)
I can manage to reproduce the problem on Nightly64.0a1 64bit (20180905123750) win10.
And I cannot reproduce the problem on Nightly64.0a1 (20180907100116) anymore.
Status: RESOLVED → VERIFIED
Comment on attachment 9004252 [details] [diff] [review]
Revert change to menu.xml to use the boxObject of the inner scrollbox and not to arrowscrollbox

Approval Request Comment
[Feature/Bug causing the regression]: bug 1454358 
[User impact if declined]: see comment 0
[Is this code covered by automated tests?]: apparently not :(
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: 
[List of other uplifts needed for the feature/fix]: /
[Is the change risky?]: no
[Why is the change risky/not risky?]: this is basically a partial backout of bug 1454358
[String changes made/needed]: /
Attachment #9004252 - Flags: approval-mozilla-beta?
Comment on attachment 9004252 [details] [diff] [review]
Revert change to menu.xml to use the boxObject of the inner scrollbox and not to arrowscrollbox

Uplift approved for 63 beta 5.
Attachment #9004252 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I cannot reproduce the issue in question. I tried to reproduce on Nightly v63.0a1 (2018-08-17). It seems easy for me to drag and drop a bookmark into a folder and the drop-down only appears when the user drags the bookmark over the folder (likely to the center of the folder tag).
Alice, can you write a more detailed STR or record a video?

Thank you!
Flags: needinfo?(alice0775)
Attached video screencast
Flags: needinfo?(alice0775)
(In reply to Bodea Daniel [:danibodea] from comment #12)
> I cannot reproduce the issue in question. I tried to reproduce on Nightly
> v63.0a1 (2018-08-17). It seems easy for me to drag and drop a bookmark into
> a folder and the drop-down only appears when the user drags the bookmark
> over the folder (likely to the center of the folder tag).
> Alice, can you write a more detailed STR or record a video?
> 
> Thank you!

The screencast(attachment 9007822 [details]) is Nightly63.0a1(m-c 20180801095107).
I'm having a really hard time trying to reproduce it. 

I have tried several builds:
1. From the day of the report: 2018-08-17 - http://archive.mozilla.org/pub/firefox/nightly/2018/08/2018-08-17-10-01-05-mozilla-central/firefox-63.0a1.en-US.win64.installer.exe
2. From after the push date of the regression window: 2018-07-15 - http://archive.mozilla.org/pub/firefox/nightly/2018/07/2018-07-15-10-01-11-mozilla-central/firefox-63.0a1.en-US.win64.installer.exe
3. From the same day as the build that was reproduced on in comment 8: 2018-09-05 - http://archive.mozilla.org/pub/firefox/nightly/2018/07/2018-07-15-10-01-11-mozilla-central/firefox-63.0a1.en-US.win64.installer.exe
  - I have to mention that I cannot find (in the archive) the specific build mentioned in comment 8, 20180905123750.
4. From the day of the regression window push: 2018-07-13 - http://archive.mozilla.org/pub/firefox/nightly/2018/07/2018-07-13-10-01-16-mozilla-central/firefox-63.0a1.en-US.win64.installer.exe
5. And many other random builds in between on 3 different OSes.

I could not reproduce the behavior seen in the attached video. There must be some small detail I am missing in my repro steps or maybe it's related to some third-party addon/extension or theme. Are you using any of those?
I can't validate it if I can't reproduce it on my system. 

I am sorry to over-complicate things, but I need to find out how you reproduce it:
A. Are you using any addons/extensions? You can check in the "about:addons" page, Extensions and Themes tabs/sections.
B. Can you reproduce it on a newly created profile? Info below:
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager
C. Where can I get the build you reproduced it on in comment 8 (Nightly64.0a1 64bit (20180905123750))? I can't find it in the archive (http://archive.mozilla.org/pub/firefox/nightly/).
 
Thank you, Alice!
Flags: needinfo?(alice0775)
(In reply to Bodea Daniel [:danibodea] from comment #15)
> A. Are you using any addons/extensions? You can check in the "about:addons"
> page, Extensions and Themes tabs/sections.

no, I can reproduce the bad builds with clean new profile.

> B. Can you reproduce it on a newly created profile? Info below:
> https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-
> firefox-profiles?redirectlocale=en-US&redirectslug=Managing-
> profiles#w_starting-the-profile-manager

Yes I can reproduce on a newly created profile.

> C. Where can I get the build you reproduced it on in comment 8
> (Nightly64.0a1 64bit (20180905123750))? I can't find it in the archive
> (http://archive.mozilla.org/pub/firefox/nightly/).
>  

The bad build in comment #0
https://queue.taskcluster.net/v1/task/DNCM59X5TP2O9DmHSCozAA/runs/0/artifacts/public/build/target.zip
And also the build in comment #8
https://queue.taskcluster.net/v1/task/YeLYw6BaRfC5oBC5vV80NA/runs/0/artifacts/public/build/target.zip
Flags: needinfo?(alice0775)
Thanks Alice for all the additional information and help. Unfortunately, with all the additional steps, new profile or otherwise, the bookmarks movement to subfolder works just fine for me with the affected build: I don't manage to reproduce the initial problem, the subfolder opens before I get the spacing line (as expected and not as you get in the attached video).
Since I see no relevant reason to continue pursuing this reproduction issue, can you please assist and verify it in beta 63 as well?
Flags: needinfo?(alice0775)
I manage to reproduce the issue on Beta63.0b4(20180906162647).
And, I cannot reproduce on Beta63.0b5(20180910132416) anymore.
Flags: needinfo?(alice0775)
Thank you, Alice!
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.