307086 - Recent OS/2 trunk builds: drag and drop does not work

Status: RESOLVED FIXED

(Core Graveyard :: Widget: OS/2, defect)

Description

[Mikus Grinbergs]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a1) Gecko/20050904 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a1) Gecko/20050904 Firefox/1.6a1

View -> Toolbars -> Customize  brings up "Customize Toolbar" window.  But when I
try to drag an object from that window (or from the Deer Park toolbars), the
cursor ALWAYS has the "No Entry" shape (black circle with white horizontal band
in the middle), and I __cannot__ drop that object anywhere.

Reproducible: Always

Steps to Reproduce:
1. View -> Toolbars -> Customize
2. Try to drag an object (icon)
3. Cannot be dropped

Actual Results:  
The "Customize Toolbar" window remains unchanged.
The Deer Park toolbars remain unchanged.

Expected Results:  
The software should have allowed me to move the objects (icons).

When I compiled from the trunk a month ago, toolbar customization worked fine.

about:buildconfig

Build platform
target
i386-pc-os2-emx

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.3.5 (Innotek Build 2005-07-18 03:46) 	-Wall -W -Wno-unused
-Wpointer-arith -Wcast-align -Wno-long-long -pedantic -Zomf -pipe
g++ 	gcc version 3.3.5 (Innotek Build 2005-07-18 03:46) 	-fno-rtti
-fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor
-Wno-long-long -pedantic -Zomf -pipe

Configure arguments
--enable-application=browser --enable-application=browser --enable-optimize
--enable-crypto --disable-debug --disable-tests --disable-updater
--disable-profilesharing

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050904
Firefox/1.6a1 ID:2005090421

Works for me with a new profile. Maybe an extension is causing this?

Comment 2

[Mikus Grinbergs]

I installed Deer Park in its own new directory, and let it create its own new
profile.  (Though I did add some customization to prefs.js.  But I see nothing
there that would explain my problem.  Remember, the same install procedure used
to work.)

I have not installed any extensions myself.  (Except these days, Deer Park seems
to automatically <under the covers> install some things with incomprehensible
names but labeled "extensions".)

Comment 3

[Peter Weilbacher]

Yes, this was discovered a few days ago in Seamonkey by Bill Hartzell who posted
the problem in the newsgroup, and I see the same in my builds. Dropping does not
work anywhere in the Mozilla programs on OS/2 AFAICS. Rich wanted to take a look
but probably didn't have time yet. Thanks for opening the bug, I change the
title to reflect the real problem.

Bill complained first on Aug 24th, so the relevant checkin must be here somewhere:
http://bonsai.mozilla.org/cvsquery.cgi?module=SeaMonkeyAll&date=explicit&mindate=2005-08-21&maxdate=2005-08-24
I find nothing obvious, the most relevant seems to be bug 296036 but I could be
wrong.

Comment 4

[Rich Walsh]

The problem here is that dragover events aren't being dispatched to the content
that should handle them.  The event-dispatcher relies on new code added by Bug
#296306 to map mouse events to content so it can know where to send them. 
Because OS/2 describes its dragovers as GUI events, they don't get mapped
correctly and end up being misdirected.

The attached patch fixes this by adding a new method, DispatchDragDropEvent(),
to nsWindow which identifies dragovers & drops as mouse events.

Comment 5

[Rich Walsh]

Attachment: patch to fix drag & drop on OS/2

Comment 6

[Rich Walsh]

I forgot to mention:  in my patch, changes to InitEvent() are largely cosmetic
(mostly whitespace).  There's also a trivial change to DispatchAppCommandEvent()
- it had the wrong return type.

Comment 7

[Peter Weilbacher]

Comment on attachment 195248 [details] [diff] [review]
patch to fix drag & drop on OS/2

>+  event.time = WinQueryMsgTime( 0/*hab*/);
>+  return;

I think you can remove this return and while you fixed the white spaces in
front of each line, could you also get rid of the spaces after brackets?
Someone in the past seems to have liked them for a reason I don't understand
but as it is not consistent througout the file anyway...

But let me try to play with the patch a bit before I mark it r+ or before you
make a new one, I do not understand everything in nsWindow just by looking at
it.

Comment 8

[Peter Weilbacher]

Comment on attachment 195248 [details] [diff] [review]
patch to fix drag & drop on OS/2

OK, seems alright otherwise and I think I understand the patch better now (and
learned a bit about event processing :-) ).

Comment 9

[Mike Kaply [:mkaply]]

Comment on attachment 195248 [details] [diff] [review]
patch to fix drag & drop on OS/2

sr=mkaply

Comment 10

[Mike Kaply [:mkaply]]

This is trunk only, correct?

Comment 11

[Peter Weilbacher]

Yes, on the 1.8 branch it wasn't broken.

Comment 12

[Mike Kaply [:mkaply]]

Fix checked in.