Closed
Bug 1484176
Opened 6 years ago
Closed 6 years ago
Bookmarks sub-folder menupopup would not open when dragover onto the sub-folder. It became very difficult to open folder.
Categories
(Toolkit :: UI Widgets, defect, P1)
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)
3.11 KB,
patch
|
dao
:
review+
pascalc
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
4.13 MB,
video/mp4
|
Details |
[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)
Updated•6 years ago
|
Priority: -- → P1
Whiteboard: [fxsearch]
Updated•6 years ago
|
Component: Bookmarks & History → XUL
Product: Firefox → Core
Tracked for 63 since it's a new regression.
Assignee | ||
Comment 3•6 years ago
|
||
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Flags: needinfo?(enndeakin)
Assignee | ||
Updated•6 years ago
|
Attachment #9004252 -
Flags: review?(dao+bmo)
Updated•6 years ago
|
Attachment #9004252 -
Flags: review?(dao+bmo) → review+
Updated•6 years ago
|
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
Comment 5•6 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Updated•6 years ago
|
Flags: qe-verify+
Comment 6•6 years ago
|
||
Dao, can we backport to 63 to fix the regression? Thanks
Flags: needinfo?(dao+bmo)
Reporter | ||
Comment 8•6 years ago
|
||
I can manage to reproduce the problem on Nightly64.0a1 64bit (20180905123750) win10.
And I cannot reproduce the problem on Nightly64.0a1 (20180907100116) anymore.
Updated•6 years ago
|
Status: RESOLVED → VERIFIED
Comment 9•6 years ago
|
||
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 10•6 years ago
|
||
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+
Comment 11•6 years ago
|
||
bugherder uplift |
Comment 12•6 years ago
|
||
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)
Reporter | ||
Comment 13•6 years ago
|
||
Flags: needinfo?(alice0775)
Reporter | ||
Comment 14•6 years ago
|
||
(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).
Comment 15•6 years ago
|
||
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)
Reporter | ||
Comment 16•6 years ago
|
||
(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)
Comment 17•6 years ago
|
||
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)
Reporter | ||
Comment 18•6 years ago
|
||
I manage to reproduce the issue on Beta63.0b4(20180906162647).
And, I cannot reproduce on Beta63.0b5(20180910132416) anymore.
Flags: needinfo?(alice0775)
You need to log in
before you can comment on or make changes to this bug.
Description
•