The default bug view has changed. See this FAQ.

Tab drag and drop does not work correctly on OS/2




DOM: Events
12 years ago
11 years ago


(Reporter: Peter Weilbacher, Assigned: Peter Weilbacher)


({fixed1.8.0.2, fixed1.8.1})

1.8 Branch
fixed1.8.0.2, fixed1.8.1

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nvn-dl])


(1 attachment)



12 years ago
As discussed about two weeks ago in netscape.public.mozilla.os2 Firefoxes tab drag and drop feature is broken on the branch (OS/2 only, but working on the trunk) in such a way that one can always only drag any tab to the far right but nowhere else. The same is true for SeaMonkey after applying the respective patch from bug 105885, so it is an issue in the backend.

I tried a bit of debugging using JS dump() in tabbrowser.xml and it turns out that aEvent.clientX is undefined in <method name="getNewIndex">, so the comparison here
is always wrong and always only the number of tabs is returned. It's late so I give up for now but it seems that during drag events this clientX is not computed (is this the one from nsDOMMouseEvent::GetClientX?).

Comment 1

12 years ago
What about this fix that only went in the trunk?

Comment 2

12 years ago
That is the patch from bug 286555 (which is marked fixed1.8) and I can see it in my branch code. I will keep looking.

Comment 3

11 years ago
I have looked into this on and off over the last week but so far haven't been successful. What I did look at so far indicates that on the trunk a call of nsDOMMouseEvent::GetClientX that is done through the JavaScript handler (I see js_Invoke, XPTC_InvokeByIndex on the call stack) while on the branch this call does not happen. It's really difficult to debug this properly, whenever I initiate a drag the debugger crashes and takes the program with it. :-(

I also managed to get the patches from bug 296036, bug 306222, and bug 307086 into my branch tree but that didn't help. Bug 306202 talks about clientX/Y although in a very different context, so it is not really of any help.

roc, bz, you are not involved in the OS/2 port but perhaps you have some idea what could be behind this?

Comment 4

11 years ago
Now, after several hours of compiling trunk Firefoxes between the branching and 2005-09-14 when the problem was fixed I am pretty sure that the patch from bug 307086 is the key. I think when I applied it last week I tried to combine it with one of the other patches I listed earlier and then it failed. Branch patch coming soon.

Comment 5

11 years ago
Created attachment 205688 [details] [diff] [review]
Tab d&d fix, part of patch from bug 307086

OK, it is again late at night but I think this time I got it right and this does indeed fix the problem...
Assignee: events → mozilla
Attachment #205688 - Flags: review?(mozilla)

Comment 6

11 years ago
What exactly is different about this new path?

Comment 7

11 years ago
Sorry, should have said that right away. It leaves out Rich's whitespace cleanup (and hence does not require the change from event.point to event.refPoint that was done on the trunk).

Comment 8

11 years ago
Review reminder for mkaply... :-)

Comment 9

11 years ago
Comment on attachment 205688 [details] [diff] [review]
Tab d&d fix, part of patch from bug 307086


I'll try to remember to put this in the 1.8 builds
Attachment #205688 - Flags: review?(mozilla)
Attachment #205688 - Flags: review+
Attachment #205688 - Flags: approval1.8.1+
Attachment #205688 - Flags: approval1.8.0.2+

Comment 10

11 years ago
Fix checked in to branches
Last Resolved: 11 years ago
Keywords: fixed1.8.0.2, fixed1.8.1
Resolution: --- → FIXED


11 years ago
Whiteboard: [nvn-dl]
You need to log in before you can comment on or make changes to this bug.