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

RESOLVED FIXED

Status

Core Graveyard
Widget: OS/2
--
major
RESOLVED FIXED
13 years ago
4 years ago

People

(Reporter: Mikus Grinbergs, Assigned: Rich Walsh)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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
(Reporter)

Updated

13 years ago
Version: unspecified → Trunk
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?
(Reporter)

Comment 2

13 years ago
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

13 years ago
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.
Status: UNCONFIRMED → NEW
Component: Toolbars → Widget: OS/2
Ever confirmed: true
Product: Firefox → Core
Summary: Recent OS/2 trunk builds: toolbars -> customize does not work (can't drag) → Recent OS/2 trunk builds: drag and drop does not work
(Assignee)

Comment 4

13 years ago
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.
(Assignee)

Comment 5

13 years ago
Created attachment 195248 [details] [diff] [review]
patch to fix drag & drop on OS/2
Attachment #195248 - Flags: review?(mozilla)
(Assignee)

Comment 6

13 years ago
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

13 years ago
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

13 years ago
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 :-) ).
Attachment #195248 - Flags: review?(mozilla) → review+

Updated

13 years ago
Assignee: nobody → dragtext
(Assignee)

Updated

13 years ago
Attachment #195248 - Flags: superreview?(mozilla)

Comment 9

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

sr=mkaply
Attachment #195248 - Flags: superreview?(mozilla) → superreview+

Comment 10

13 years ago
This is trunk only, correct?

Comment 11

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

Comment 12

13 years ago
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.