Created attachment 504405 [details] Screenshot 1 Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20110116 Firefox/4.0b10pre Reproducible: Always When closing multiple tabs in panorama view using middle click, empty spaces are created which are not filled by following tabs. (See screenshot) Steps to reproduce: 1. Open multiple tabs 2. Go to panorama 3. Middle click one of the tabs (hold click down and drag the tab a bit in any direction) Actual results: - an empty space is left in the group Expected results: - the tab closes and the following tab takes its place in the group Additional information: - in tab view, the closed tabs from panorama are still present
Screenshot 2 and Screenshot 3 come from the same session. Closed tabs in Panorama still present in tab view.
Confirming. I'm not quite sure what the behaviour should be. Should the tab be closed when dragging with the middle mouse button?
Assignee: nobody → tim.taubert
Status: NEW → ASSIGNED
OS: Windows 7 → All
Hardware: x86 → All
Version: unspecified → Trunk
Middle mouse dragging is not used in tab view, maybe it shouldn't be used in Panorama either.
(In reply to comment #4) > I'm not quite sure what the behaviour should be. Should the tab be > closed when dragging with the middle mouse button? Indeed, based on our code, I would have expected this behavior to be the same as left-click dragging. The question, then, is how did the tab close. I unfortunately don't have a middle button and don't know how to simulate one easily so it's hard for me to reproduce this and investigate... :(
Created attachment 504536 [details] [diff] [review] patch v1 This patch disables drag/drop via middle click for groups and tabs.
Created attachment 504967 [details] [diff] [review] patch v1b (unrotted)
Created attachment 504968 [details] [diff] [review] patch v1c (unrotted)
Comment on attachment 504968 [details] [diff] [review] patch v1c (unrotted) Looks good. >- if (Utils.isRightClick(e)) >+ if (Utils.isRightClick(e) || e.button == 1) Maybe we want a Utils.isMiddleClick()? For that matter, are there other places we use isRightClick where we should also be checking for middle click? If so, fix here or file follow ups.
Attachment #504968 - Flags: review?(ian) → review+
Created attachment 505667 [details] [diff] [review] patch v2 (In reply to comment #11) > Maybe we want a Utils.isMiddleClick()? > > For that matter, are there other places we use isRightClick where we should > also be checking for middle click? If so, fix here or file follow ups. There is now Utils.isMiddleClick() and Utils.isLeftClick(). I replaced isRightClick() at the places where we also want to check for middle click.
Comment on attachment 505667 [details] [diff] [review] patch v2 a=beltzner, thanks for tests!
Attachment #505667 - Flags: approval2.0? → approval2.0+
Created attachment 506882 [details] [diff] [review] patch for checkin
Attachment #505667 - Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Backed out: http://hg.mozilla.org/mozilla-central/rev/21a7c88123ca This one was backed out together with bug 625424 but this one does not cause orange. So please feel free to push again :)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b11
Mozilla/5.0 (Windows NT 6.1; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre Confirming fix.
verified with nightly build of minefield.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.