Closed Bug 1483786 Opened Last year Closed Last year
New windows created from tab dragging are wrongly positioned over the parent window
[Affected versions]: - Nightly v63.0a1, Build ID 20180814100100 [Affected Platforms]: - All Windows - All Mac [Steps to reproduce]: 1. Open the browser and open a new tab. 2. Resize the Browser to half screen. 3. Drag the new tab in the empty area of the screen and release the mouse button. 4. Observe the behavior. [Expected results]: - The new tab is opened in a new window and moved in that area. [Actual results]: - The new tab is opened in a new window over the current one. [Notes]: - The issue is also reproducible when moving fullscreen windows to different displays. - The issue is not reproducible on Ubuntu 18.04 or Arch Linux. - Attached a screen recording of the issue.
1:14.13 INFO: Last good revision: 0260bc2917ddcb8166a498c6b37d643b20282276 1:14.14 INFO: First bad revision: 5ad7b28b1009149d1fb27ed6b8c5e10d2b4727ec 1:14.14 INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0260bc2917ddcb8166a498c6b37d643b20282276&tochange=5ad7b28b1009149d1fb27ed6b8c5e10d2b4727ec @Abdoulaye, it looks like Bug 1458056 has caused this behavior. Could you please take a look at this?
If GSOC is over, who is keeping on with this (and multiselect in general, bug 1458007) -- is it you, or you and Abdoulaye, or... ?
Abdoulaye is continuing to work on the feature.
Flags: needinfo?(jaws) → needinfo?(ablayelyfondou)
Can you still reproduce this issue with "browser.tabs.multiselect" set to false in about:config? Right now we are not planning on shipping the feature in 63 until we can get https://bugzilla.mozilla.org/buglist.cgi?quicksearch=whiteboard%3A[blocking-multiselect-tabs]&list_id=14285769 fixed.
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #5) > Can you still reproduce this issue with "browser.tabs.multiselect" set to > false in about:config? I can reproduce the bug in Nightly 63.0a1 (2018-08-29) (64-bit) Build-ID 20180829100131 with browser.tabs.multiselect set to False (even changed it to False, restarted Firefox, and still opens the "dropped tab" window on top of the window it came from instead of where I dragged the tab). I can also reproduce the bug in Development 63.0b1 (64-bit) Build-ID 20180824192747, which by default has browser.tabs.multiselect set to False.
If it's reproducible with browser.tabs.multiselect set to False, it's probably not introduced through multi-select tabs bugs.
I ran mozregression-gui, telling it to clone the profile where I had set browser.tabs.multiselect to False, and, alas, it lands in the same place. (I did check a couple of the builds it launched to make sure browser.tabs.multiselect was indeed False when I went into about:config; apparently mozregression-gui doesn't allow one to directly set a _Boolean_ preference to False.) 2018-08-08 Last day drag & drop of a tab to create a new window worked. 2018-08-09 First day drag & drop of a tab to create a new window created the window on top of the original window. The end of the Log file still shows: > 2018-08-29T23:21:43: INFO : Narrowed inbound regression window from [152ac3a5, 5ad7b28b] (3 builds) to [0260bc29, 5ad7b28b] (2 builds) (~1 steps left) > 2018-08-29T23:21:43: DEBUG : Starting merge handling... > 2018-08-29T23:21:43: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=5ad7b28b1009149d1fb27ed6b8c5e10d2b4727ec&full=1 > 2018-08-29T23:21:43: DEBUG : Found commit message: > Bug 1458056 - Implement ability to move a selection of tabs into another window through drag and drop. r=jaws > > MozReview-Commit-ID: LFFoE6HsBp8 > > Differential Revision: https://phabricator.services.mozilla.com/D2986 > > 2018-08-29T23:21:43: DEBUG : Did not find a branch, checking all integration branches > 2018-08-29T23:21:43: INFO : The bisection is done. > 2018-08-29T23:21:43: INFO : Stopped At the end of the run, the Bisections Informations window shows: > app_name: firefox > build_date: 2018-08-09 18:47:34.413000 > build_file: C:\Users\Mark\.mozilla\mozregression\persist\d7e4ce95a34e--autoland--target.zip > build_type: inbound > build_url: https://queue.taskcluster.net/v1/task/NAoc-LdNTJSh-YxRB_qsBg/runs/0/artifacts/public%2Fbuild%2Ftarget.zip > changeset: d7e4ce95a34e6ab71d95a1ebbc0b66e15e80faa5 > pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d7e4ce95a34e6ab71d95a1ebbc0b66e15e80faa5&tochange=5ad7b28b1009149d1fb27ed6b8c5e10d2b4727ec > repo_name: autoland > repo_url: https://hg.mozilla.org/integration/autoland > task_id: NAoc-LdNTJSh-YxRB_qsBg This was run on my Windows 10 (64-bit) machine. Is any of this useful, or is there something else I can do on my end that might help track this down?
I can confirm Mark's findings, the issue is reproducible with browser.tabs.multiselect set to false as well and it points to the same bug as in the initial report: Last good revision: 0260bc2917ddcb8166a498c6b37d643b20282276 First bad revision: 5ad7b28b1009149d1fb27ed6b8c5e10d2b4727ec Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0260bc2917ddcb8166a498c6b37d643b20282276&tochange=5ad7b28b1009149d1fb27ed6b8c5e10d2b4727ec
Speculation .... And rhetorical questions. mozregession is designed to find _when_ the bug appeared and identifies the patch at the time the bug appeared, but it is an assumption that it has found _what_ caused the bug to appear. Were there other changes that occurred on or about that time, such as a change in the libraries? Or could the code change have exposed another bug that may have remained hidden or unused until this patch started accessing it? (Having experienced new bugs when I made code changes and tracking them down to code I did not touch but started referencing has taught me that sometimes I can be too myopic on what I am looking at.)
Bug 1458056 broke this, no need to speculate.
replaceTabsWithWindow calls replaceTabWithWindow to create a new window window with a first tab. But unlike the later function, the former cited function don't take an object param (aOptions) containing informations such as the mouse position (which helps set the new window position). To adress the issue, we added support for passing an option param to replaceTabsWithWindow which just transferts the param to replaceTabWithWindow.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/06af1619a799 Add aOptions object param to 'replaceTabsWithWindow' function in browser/base/content/tabbrowser.js file. r=jaws
Comment on attachment 9005544 [details] Bug 1483786 - Add aOptions object param to 'replaceTabsWithWindow' function in browser/base/content/tabbrowser.js file. r?jaws Jared Wein [:jaws] (please needinfo? me) has approved the revision.
Attachment #9005544 - Flags: review+
Reproduced the issue with Nightly v63.0a1, Build ID 20180814100100 on Win10. Verified the fix with 63.0.1 on Win 10 and macOS 10.13; can confirm the issue is no longer reproducible.
You need to log in before you can comment on or make changes to this bug.