User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20170903140023 Steps to reproduce: 1. Have a tab with a page loaded. 2. Try and drag the identity box into the bookmarks toolbar in order to bookmark it. Actual results: The tab drop indicator started showing up in the tab bar even though the cursor was on the bookmarks toolbar. See gif - http://i.imgur.com/hkRmaVN.gif. Expected results: This is only a recent regression (likely from Bug 450915, but I will try and confirm). Previously, you would get a blue drop indicator on the bookmarks toolbar itself (as expected).

Also in Firefox Nightly 57 Build ID 20170908100218. This problem appeared in Nightly between yesterday morning and this morning.

Bug is also reproduced when dragging a tab to the bookmarks toolbar.

(In reply to Mark from comment #1) > Also in Firefox Nightly 57 Build ID 20170908100218. This problem appeared in > Nightly between yesterday morning and this morning. Oops, I'm getting inconsistent results, best discard my comments. :(

Ok, now I see the pattern. When dragging the (i) from the address bar down to the Bookmarks Toolbar (must have already enabled the Bookmarks Toolbar), the blue down-pointing triangle appears just above the Bookmarks Toolbar to indicate the place where the bookmark will be created in Nightly 2017-09-06 and before. When dragging the (i) from the address bar down to the Bookmarks Toolbar in Nightly 2017-09-07 and after, the blue down-pointing triangle is nowhere near the Bookmarks Toolbar so one doesn't know if one is in a valid place to drop (create) the bookmark or, if one does finally notices the blue down-pointing triangle up in the Tabs bar one still doesn't know where in the Bookmarks Toolbar the bookmark will be dropped (created), that is, if the blue triangle is even visible. (In some tests, the triangle wasn't visible to me and a bookmark could still be created in the Toolbar.) I then reproduced this issue on a brand new profile, no extensions, no customizations except one: I enabled the Bookmarks Toolbar. System: Windows 7 Home Premium SP1 (64-bit) Firefox: Firefox Nightly 57.0a1 (2017-09-08) (64-bit) Build ID 20170908100218. Regression to follow.

Regression! This tested whether dragging (i) from the Address Bar to the Bookmarks Toolbar showed the down-pointing blue triangle just above the Toolbar (good) or not (bad). The last part of the regression log has these lines: https://hg.mozilla.org/integration/autoland/json-pushes? changeset=1fae43b4534cf25d917e544ca02e7ad6b1aa1736&full=1 2017-09-08T15:44:39: DEBUG : Found commit message: Bug 1397236 - Changing positioning of navigator-toolbox while a descendent popup is open causes the popup to close. We don't need to change the positioning of the navigator-toolbox on the fly, and can instead always keep it as position:relative for the library animation. r=Gijs MozReview-Commit-ID: HXbjhQFCplb 2017-09-08T15:44:39: INFO : The bisection is done. 2017-09-08T15:44:39: INFO : Stopped The Bisections Information contained this at the end of the run: app_name: firefox build_date: 2017-09-07 17:11:37.778000 build_file: C:\Users\Mark12547\.mozilla\mozregression\persist\1fae43b4534c--autoland--target.zip build_type: inbound build_url: https://queue.taskcluster.net/v1/task/UMDdSMt8THGK8X6mwEoPaA/runs/0/artifacts/public%2Fbuild%2Ftarget.zip changeset: 1fae43b4534cf25d917e544ca02e7ad6b1aa1736 pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=572f37089603abbec3de4cd6d375e723c9c30cb1&tochange=1fae43b4534cf25d917e544ca02e7ad6b1aa1736 repo_name: autoland repo_url: https://hg.mozilla.org/integration/autoland task_id: UMDdSMt8THGK8X6mwEoPaA

On another bug I commented that I thought the drop zone for adding the current URL to the Bookmarks Toolbar had narrowed. After testing, I think the drop zone is just as big as before, but the lack of the blue down-pointing triangle immediately above the Bookmarks Toolbar made it difficult to know if the mouse was in the right spot to drop (create) the bookmark in the Toolbar. It also didn't help that during the regression that a number of times when the blue triangle was up in the Tabs bar the triangle wasn't there at all unless the mouse was at the very left extreme of the Toolbar. By the way, I ran the regression twice, just to make sure I didn't click on the wrong response, and both times the mozregression-gui zeroed in on the same bug.

[Tracking Requested - why for this release]: Regression window: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=481d7cc2f6f06ea35794403dc9291d277910d6b9&tochange=1fae43b4534cf25d917e544ca02e7ad6b1aa1736 Regressed by: 1fae43b4534c Jared Wein — Bug 1397236 - Changing positioning of navigator-toolbox while a descendent popup is open causes the popup to close. We don't need to change the positioning of the navigator-toolbox on the fly, and can instead always keep it as position:relative for the library animation. r=Gijs

So, I dunno what anyone else is seeing, but I see the bookmarks toolbar drag indicator, but mispositioned, and therefore showing up in the tabstrip. It doesn't actually look like the tab drag indicator we show when dragging tabs. Are other folks seeing something else?

Dragging any link(link, bookmark, tab, identify icon) over Bookmarks toolbar, the drop indicator of Bookmarks toolbar shifts to the upper side about 20-25px.

(In reply to Alice0775 White from comment #10) > Created attachment 8907595 [details] > screencast > > Dragging any link(link, bookmark, tab, identify icon) over Bookmarks > toolbar, the drop indicator of Bookmarks toolbar shifts to the upper side > about 20-25px. Thanks, that matches what I'm seeing. I'll adjust the summary again...

One day, bugzilla will have good suggestions for when people file duplicates. :-\

(In reply to :Gijs from comment #9) > So, I dunno what anyone else is seeing, but I see the bookmarks toolbar drag > indicator, but mispositioned, and therefore showing up in the tabstrip. It > doesn't actually look like the tab drag indicator we show when dragging > tabs. Are other folks seeing something else? Depending on what is on the Tab bar, in some spots the drop indicator isn't visible at all.

(In reply to Mark from comment #15) > (In reply to :Gijs from comment #9) > > So, I dunno what anyone else is seeing, but I see the bookmarks toolbar drag > > indicator, but mispositioned, and therefore showing up in the tabstrip. It > > doesn't actually look like the tab drag indicator we show when dragging > > tabs. Are other folks seeing something else? > > Depending on what is on the Tab bar, in some spots the drop indicator isn't > visible at all. Yes, if the place to drop, between existing bookmarks, is directly below the focused tab, the drop indicator is hidden by the tab. That would obviously be a non-issue if the drop indicator were at the tab bar, where it is supposed to be.

Comment on attachment 8907730 [details] Bug 1398252 - Position the personal-bookmarks toolbar so the drop indicator will be positioned relatively to the toolbar instead of the navigator-toolbox. https://reviewboard.mozilla.org/r/179404/#review184590 ::: browser/base/content/browser.css (Diff revision 1) > + position: relative; > +} > + > #PlacesToolbarDropIndicatorHolder { > position: absolute; > - top: 25%; Hrm, can you file a followup to position this better vertically? At least on OSX, looks like we should give it top: 2px. I don't know about other OSes, but either way this wasn't regressed by your change. I also noticed that when dragging along the bookmarks toolbar, the dropmarker flickers to the end when the drag hits areas between bookmarks. Again, not a regression from your change, but it would be nice to fix that in a separate bug at some point, too.

Pushed by jwein@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/85716b58bbf2 Position the personal-bookmarks toolbar so the drop indicator will be positioned relatively to the toolbar instead of the navigator-toolbox. r=Gijs

I was able to reproduce this issue on the Nightly build (20170908100218). Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 (20170915100121) This issue is verified as fixed with the latest Nightly on 9/15/2017.