Closed Bug 321578 Opened 15 years ago Closed 15 years ago

Files dragged onto tabbar from explorer don't open in new tabs anymore

Categories

(SeaMonkey :: UI Design, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: svl-bmo, Assigned: jag+mozilla)

References

Details

(Keywords: dataloss, fixed-seamonkey1.1a, regression)

Attachments

(1 file)

I always open lots of files in SeaMonkey by dragging them over onto an empty part of the tabbar directly from Explorer. Especially my photography workflow depends completely on this behaviour, as I do the first comparison of similars by quickly dragging them over to the browser to appear in tabs side by side.
Starting - presumably - with the tab reordering implementation, this doesn't work anymore, and instead new files are opened in the current tab. Highly annoying for the photography workflow - now I need to insert ctrl-t in between the drags - and potentially destructive dataloss if you drag a file over while the current tab contains formdata.

If tab reordering isn't responsible and it's unknown when this bug was introduced, let me know and I'll track down the regression window. I care a lot about this.
OS: Other → Windows 2000
This has reportedly been fixed on trunk, but still needs fixing on branch (tested with 2005122609). Can't figure out which patch it is that hasn't been checked in on branch (nor can I find a separate bug for it), so keeping this open for the nonce to help remind CTho. :)
(In reply to comment #1)
> This has reportedly been fixed on trunk, but still needs fixing on branch
> (tested with 2005122609). Can't figure out which patch it is that hasn't been
> checked in on branch (nor can I find a separate bug for it), so keeping this
> open for the nonce to help remind CTho. :)
> 

This is marked as a Trunk bug. Is there a field where it can be noted "fixed-trunk"?
Assignee: cst → neil.parkwaycc.co.uk
Version: Trunk → 1.8 Branch
This is not in fact fixed on trunk (I now figure it's windows only, and that that why it reportedly wasn't present on trunk).
Regressed between 2005121309 and 2005121409.
Version: 1.8 Branch → Trunk
Most likely a regression from bug 319244.
Assignee: neil.parkwaycc.co.uk → jag
Status: NEW → ASSIGNED
Comment on attachment 207007 [details] [diff] [review]
Null check aDragSession.sourceNode

<CTho|away> r=me
Attachment #207007 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #207007 - Flags: review+
Attachment #207007 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Checking in tabbrowser.xml;
/cvsroot/mozilla/xpfe/global/resources/content/bindings/tabbrowser.xml,v  <--  tabbrowser.xml
new revision: 1.136; previous revision: 1.135
done
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Attachment #207007 - Flags: approval-seamonkey1.1?
Comment on attachment 207007 [details] [diff] [review]
Null check aDragSession.sourceNode

a=me for 1.1

For 1.0, count in my a+ as well, but needs one other Council member to agree.
Attachment #207007 - Flags: approval-seamonkey1.1?
Attachment #207007 - Flags: approval-seamonkey1.1+
Attachment #207007 - Flags: approval-seamonkey1.0?
Comment on attachment 207007 [details] [diff] [review]
Null check aDragSession.sourceNode

a=me for 1.0
Attachment #207007 - Flags: approval-seamonkey1.0? → approval-seamonkey1.0+
Hmm, it looks like this was never checked in to MOZILLA_1_8_BRANCH.
I checked in to the 1_8_0_BRANCH sometime last week. Just now I did the 1_8_BRANCH.

Checking in tabbrowser.xml;
/cvsroot/mozilla/xpfe/global/resources/content/bindings/tabbrowser.xml,v  <--  tabbrowser.xml
new revision: 1.126.2.9; previous revision: 1.126.2.8
done
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.