11397 - [Dogfood] Regression: d&d too sensitive on toolbars

Status: VERIFIED DUPLICATE of bug 11826

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[esther]

Using 19990806 build on win95 the Toolbar buttons are slow to act and sometimes
needs to be clicked several times to bring up the window.  Need to check Linux
and Mac now.  Not sure if this is happening in Browser, it seems to be acting ok

1. Launch Messenger
2. Click the New Msg toolbar button
Notice:
a.) it takes at least 4 seconds for the New Msg to come up (I'm using a Compaq
133 which is slow, but this is much slower than previous builds)
b.) it doesn't come up until you click it again, sometimes multiple times.

This is also true when you are in the Address Book and click New Card or Edit
Card.

Comment 1

[Ninoschka Baca]

Build 1999080608M9: Win32/NT4

This is the output from the Console when clicking on New Message button:

->>>>>>>>>>>>>> Write Clipboard to memory
nsClipboard::GetFormat [moz/toolbaritem] 0xc0d6
nsDataObjCollection::EnumFormatEtc
nsClipboard::GetFormat [Mozilla/IDataObjectCollectionFormat] 0xc0d4
nsDataObjCollection::QueryGetData  format: 15  Mulitple: 49364
***** nsDataObjCollection::QueryGetData - Unknown format 15
nsDataObjCollection::EnumFormatEtc
nsClipboard::GetFormat [Mozilla/IDataObjectCollectionFormat] 0xc0d4
nsClipboard::GetFormat [Mozilla/IDataObjectCollectionFormat] 0xc0d4
nsDataObjCollection::QueryGetData  format: 49364  Mulitple: 49364
nsClipboard::GetFormat [moz/toolbaritem] 0xc0d6
nsClipboard::GetFormat [Mozilla/IDataObjectCollectionFormat] 0xc0d4
nsClipboard::GetFormat [Mozilla/IDataObjectCollectionFormat] 0xc0d4
nsDataObjCollection::QueryGetData  format: 49364  Mulitple: 49364
nsClipboard::GetFormat [moz/toolbar] 0xc0d3
nsDataObjCollection::EnumFormatEtc
nsClipboard::GetFormat [Mozilla/IDataObjectCollectionFormat] 0xc0d4
nsClipboard::GetFormat [Mozilla/IDataObjectCollectionFormat] 0xc0d4
nsDataObjCollection::QueryGetData  format: 49364  Mulitple: 49364
nsClipboard::GetFormat [Mozilla/IDataObjectCollectionFormat] 0xc0d4
nsClipboard::GetFormat [Mozilla/IDataObjectCollectionFormat] 0xc0d4
nsDataObjCollection::QueryGetData  format: 49364  Mulitple: 49364
nsClipboard::GetFormat [moz/toolbaritem] 0xc0d6
S_OK
nsDataObj::GetData2
->>>>>>>>>>>>>> Read Clipboard from memory
S_OK
nsClipboard::GetFormat [text/html] 0xc0d2
->>>>>>>>>>>>>> Write Clipboard to memory
->>>>>>>>>>>>>> Read Clipboard from memory
Dropped: toolbar item
nsClipboard::GetFormat [Mozilla/IDataObjectCollectionFormat] 0xc0d4
nsClipboard::GetFormat [Mozilla/IDataObjectCollectionFormat] 0xc0d4
nsDataObjCollection::QueryGetData  format: 49364  Mulitple: 49364
nsClipboard::GetFormat [Mozilla/IDataObjectCollectionFormat] 0xc0d4
nsClipboard::GetFormat [Mozilla/IDataObjectCollectionFormat] 0xc0d4
nsDataObjCollection::QueryGetData  format: 49364  Mulitple: 49364
nsClipboard::GetFormat [moz/toolbar] 0xc0d3
****** DisplayErrCode 0x80004005

Comment 2

[scottputterman]

reassigning to XPToolkit as a first guess.  So, if I click straight down on a
button, this doesn't happen. But when I move the mouse a little bit while
clicking down, this does happen.  It looks like drag and drop is interfering
with mouse clicks.

Comment 3

[Peter Trudelle]

reproduced in 8/8 opt build, reassigning to pinkerton as p3(workarounds exist,
right?) for m9

Comment 4

[Mike Pinkerton (not reading bugmail)]

yeah, our d&d is probably too sensitive. should I just totally co-opt this bug
into that (with a low priority), or do people still feel like this is a major
dogfood issue?

Comment 5

[scottputterman]

I've actually been hitting this quite a bit over the last couple of days.  I
think this is a useability issue, so if it's not too hard to fix, I'd like to
see it fixed.

Comment 6

[Mike Pinkerton (not reading bugmail)]

this is going to take a little bit of thought and rearchitecting. i'll work on
it, but i can't promise anything.

i've tried playing with it, and yes it is annoying, but the buttons still do the
right thing even if they do the extra d&d stuff. I don't think the d&d is slowing
anything down, per se. Remember that we don't show the window until all the
chrome is loaded. That takes time.

changing platform to all, since this affects us everywhere. updating summary.
accepting bug.

Comment 7

[scottputterman]

The mailnews ones, at least, don't do the right thing.  You have to hit them
exactly right or the command doesn't get executed.  I've seen people hit them 4
or 5 times w/o the command getting executed.

Comment 8

[Mike Pinkerton (not reading bugmail)]

ok, i'll play with it some more on win32.

Comment 9

[Mike Pinkerton (not reading bugmail)]

ordered by my boss to get this off the m9 radar. I'm still thinking about it, but
it requires api changes i'm not in a rush to make (see my post to .xpfe regarding
it).

Comment 10

[Mike Pinkerton (not reading bugmail)]

tweak checked in to disable this for M9. I'll get a real solution by M10 (see
newsgroups for discussions of fixes).

Comment 11

[Mike Pinkerton (not reading bugmail)]

marking this as a dupe of 11826 because that's the bug with the work scheduled to
make d&d not so sensitive.


*** This bug has been marked as a duplicate of 11826 ***

Comment 12

[Jay Patel [:jay]]

verified dup...see Bug 11826

Comment 13

[Stephen P. Morse]

*** Bug 11967 has been marked as a duplicate of this bug. ***

Comment 14

[Stephen P. Morse]

Ignore above auto-generated comment.  Bug 11967 was not marked as a duplicate of
this bug -- it was marked as a duplicate of bug 11317 instead.  Sorry for the
confusion.

Comment 15

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/d249fafe083a
[fenix] For https://github.com/mozilla-mobile/fenix/issues/11397 - Add lint rule for AppCompatResources instead of ContextCompat (https://github.com/mozilla-mobile/fenix/pull/16011)