274205 - drag and drop does not open window minimized on taskbar

Status: NEW

(Core :: Widget: Win32, defect, P3)

Description

[ljbmailprotect-mozilla]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

If you minimize a browser window in firefox, then drag and drop a URL from the
location bar to the task bar icon containing the minimized window the window
does not open up to allow the drop.  

If the window was not minimized but instead you swithed to the other window the
drag and drop works normally.

Reproducible: Always
Steps to Reproduce:
1.open 2nd window in ff
2.minimize it
3.drag and drop from the location bar of the first window to the task bar icon
of the second ff window

Comment 1

[Mike Connor [:mconnor]]

WFM on 1.0/WinXP, dragging any draggable content (URLs, text, etc) restores the
window and allows dropping.

Testing on Win2k would be good too.  If this is only in Win98 I'm not sure this
is going to get any attention.

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[ljbmailprotect-mozilla]

Yes I can still reproduce this bug using ff1.7
Someone please confirm that you can reproduce it too.

Add'l notes to reproduce:
1. minimize using the button on the upper right of the window to reproduce the
failure
2. if you switch windows using Alt-tab it works normally without failure.


(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0
> Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0
> 
> If you minimize a browser window in firefox, then drag and drop a URL from the
> location bar to the task bar icon containing the minimized window the window
> does not open up to allow the drop.  
> 
> If the window was not minimized but instead you swithed to the other window the
> drag and drop works normally.
> 
> Reproducible: Always
> Steps to Reproduce:
> 1.open 2nd window in ff
> 2.minimize it
> 3.drag and drop from the location bar of the first window to the task bar icon
> of the second ff window

Comment 4

[Jennifer]

I was able to reproduce this problem on the following configuration:
Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060124 Firefox/1.6a1
OS: Windows XP Pro SP 2

I had several other applications minimized, and dragging the text from the location bar over any of their taskbar icons did result in those applications maximizing, but the Firefox browser did not maximize.

Comment 5

[ljbmailprotect-mozilla]

(In reply to comment #4)
> I was able to reproduce this problem on the following configuration:
> Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060124
> Firefox/1.6a1
> OS: Windows XP Pro SP 2
> 
> I had several other applications minimized, and dragging the text from the
> location bar over any of their taskbar icons did result in those applications
> maximizing, but the Firefox browser did not maximize.
> 


I was also now able to confirm the bug using XP Pro SP2 and FF 1.5.0.1

Comment 6

[ljbmailprotect-mozilla]

Someone with the power needs to change the status of this bug from uncomfirmed to new since several people have already confirmed the bug.

Comment 7

[Mike Connor [:mconnor]]

Note that dragging from other apps seems to work, its dragging from within one Firefox to another that this seems to fail.

Comment 8

[ljbmailprotect-mozilla]

I have now been able to confirm the bug exists in the latest FF version 2.0.0.2 using XP Pro on an entirely separate notebook PC in addition to the original PC I discovered the bug on.  

The key is that you must minimize the 2nd FF window not Alt-tab away from it.

Comment 10

[Robert Strong (they/them - no direct email)]

A simple fix would be to restore the window in the WM_ACTIVATE when fActive is WA_ACTIVE and fMinimized is true

Comment 11

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1 - implement comment #10

Jim, I'd like to get your input on this approach. Thanks!

Comment 12

[Robert Strong (they/them - no direct email)]

Hey Jeff, I don't know of a decent way to write a test for this... do you? btw: I also asked Roc in person and we weren't able to come up with a decent way.

Comment 13

[Jim Mathies [:jimm]]

This isn't going work because you'll receive an activate message when you minimize the window to the app bar by clicking on the app bar slot. You'll also get one when you minimize Fx and then close the active window behind it. What I haven't figured out is why this isn't working with default processing. I'm guessing it has something to do with the main thread being caught up in the DoDragDrop call in the foreground window. There was a bug related to this recently where window events weren't getting processed, but that's been fixed, but still something in here isn't working right.

Also, I noticed we're returning WM_MOUSEACTIVATE return values for WM_ACTIVATE when result is true. It looks like result will usually be false so we'll fall through to DefWndProc, but still this might be causing problems somewhere. 

Comment 14

[Robert Strong (they/them - no direct email)]

Thanks Jim... that makes sense. Do you know the bug number for the bug you referenced?

Comment 15

[Jim Mathies [:jimm]]

Yep - bug 337761. It's fixed though, so it's not causing this problem. I did some debugging - changed up return values, various parameter checks on the patch, etc.. I wasn't able to come up with something that was reliable. In general Windows didn't seem to like what we are doing - even when I found a local solution in WM_ACTIVATE's code, windows 'beeped' at me complaining. Which leads me to believe this is more than skin deep. 

Comment 16

[Robert Strong (they/them - no direct email)]

Jim, the patch for bug 337761 doesn't appear to have been checked in.

Comment 17

[Robert Strong (they/them - no direct email)]

Perhaps bug 389931?

Comment 18

[Jim Mathies [:jimm]]

Yers that's correct. We worked on 337761 but somebody else working on 389931 found the right fix.

Comment 19

[Jeff Walden [:Waldo]]

Yeah, I wouldn't bother with trying to test this in an automated manner, just litmus for the win.

Comment 20

[Jim Mathies [:jimm]]

Attachment: task bar drag patch v.1

A better implementation of our handling of WM_ACTIVATE in cases where the activation isn't caused by the mouse.

Comment 21

[Ere Maijala (slow)]

Comment on attachment 361394 [details] [diff] [review]
task bar drag patch v.1

No go. This makes it impossible to minimize the window by clicking its taskbar button. It also causes onfocus of a text field to fire three times in the test case of bug 261074.

Comment 22

[Jim Mathies [:jimm]]

(In reply to comment #21)
> (From update of attachment 361394 [details] [diff] [review])
> No go. This makes it impossible to minimize the window by clicking its taskbar
> button. It also causes onfocus of a text field to fire three times in the test
> case of bug 261074.

Hmm, bummer, I'll take another look.

Comment 24

[Teoh Han Hui]

Failed to reproduce on: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091119 Minefield/3.7a1pre

This bug should already be fixed, as is its duplicate Bug 483475.

Comment 25

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to comment #7)
> Note that dragging from other apps seems to work, its dragging from within one
> Firefox to another that this seems to fail.

I still see this on trunk, but it only occurs when you're dragging stuff within one Fx process.  If you have say 3.5 and trunk running side by side (with no-remote) then this works on any drag that starts in one process and ends in another.

Comment 26

[Jim Mathies [:jimm]]

If someone would like to take a shot at fixing this feel free.

Comment 27

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Also interesting, Chrome and Safari have the same problem.  Works in IE though.

Comment 28

[Teoh Han Hui]

My apologies. This behaviour is not observed when browser.taskbar.previews.enable is set to true.

Comment 30

[Brian R. Bondy [:bbondy]]

I'm still in the middle of investigating this, but I have a few observations:

- Using Spy++ I seen that WM_SYSCOMMAND is sent with WPARAm SC_RESTORE to the minimized window you are dropping on.
A little strange to me is that even before it hits nsWindow, in the main message handling code inside nsAppShell it does not see this WM_SYSCOMMAND message at all. (Inside the message handling w/ PeekUIMessage, PeekMessage, TranslateMessage, DispatchMessage)

- I can easily reproduce 100% of the time both with browser.taskbar.previews.enable set to true and false.

- Google Chrome has the exact same behavior as us when dragging from within the app to a minimized window, and like us not when dragging from an external program to it.

- Microsoft word has the exact same behavior as us when dragging from within the app to a minimized window, and like us not when dragign from an external program to it.

- IE9 does NOT have this behavior, it works correctly even when dragging from within.
  It has a couple of additional messages sent probably from within its app itself.
  

Sequence of IE messages without the problem:

WM_WINDOWPOSCHANGING
WM_WINDOWPOSCHANGED
WM_ACTIVATEAPP
WM_ACTIVATE wParam: 200001
WM_CHANGEUISTATE
WM_SYSCOMMAND (SC_RESTORE)
WM_QUERYOPEN
WM_WINDOWPOSCHANGING
...

Sequence of other apps with the problem:

WM_WINDOWPOSCHANGING
WM_WINDOWPOSCHANGING
WM_WINDOWPOSCHANGED
WM_ACTIVATE minimize true
WM_SYSCOMMAND (SC_RESTORE), but can't see it when debugging top level message handling.

Comment 31

[Brian R. Bondy [:bbondy]]

I also checked to see if maybe we were consuming the message from a different PeekMessage w/remove or GetMessage or windows hook, but it does not seem to be the case.

Comment 32

[Jim Mathies [:jimm]]

You might check the data format requests coming into the nsDataObj for the drag. Explorer might be looking for something we aren't providing.

Comment 33

[Brian R. Bondy [:bbondy]]

OK Thanks I did want to also check into the drag-source code.  I'll advise when I have more info.

Comment 34

[Brian R. Bondy [:bbondy]]

One thing relating to that though is that it works when the window is not minimized.

Comment 35

[Brian R. Bondy [:bbondy]]

Regarding:

> - Using Spy++ I seen that WM_SYSCOMMAND is sent with WPARAm SC_RESTORE to the minimized window you are dropping on. A little strange to me is that even before it hits nsWindow, in the main message handling code inside nsAppShell it does not see this WM_SYSCOMMAND message at all. (Inside the message handling w/ PeekUIMessage, PeekMessage, TranslateMessage, DispatchMessage)

It's possible that windows or another application can send a non queued message directly to the wnd proc.  It turns out though that this is not even being done for the lost message in question.   

I can easily come up with similar patches to what was submitted


I'm moving to another task temporarily for now.

Comment 36

[Brian R. Bondy [:bbondy]]

I meant to say I can come up with similar patches to what was submitted but they have their quirks and it still does this strange system beep.  MS Word and Chrome have the exact issue we do, Explorer and IE seem to work.

Comment 37

[alex_mayorga]

I just got bitten by this bugger on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111115 Firefox/11.0a1 ID:20111115030957

Don't know if it's relevant but I noticed that the "system bell" rings at the time the minimized window should maximize.

Comment 38

[Brian R. Bondy [:bbondy]]

Won't be touching this in a while so marking as free to take.

Comment 39

[u518207]

Maybe we need a handle to the minimized window to send it the corresponding message.

Comment 40

[kapil chhajer [:kaps]]

hello, is somebody working on this bug because i would like to work on this bug, i know c++ this would be my first bug so i might need some extra guidance debugging it. thanks!

Comment 41

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

@ kapil chhajer [:kaps] - speak to Jim Mathies [:jimm] as he's the mentor of this bug

Comment 42

[Jim Mathies [:jimm]]

[e-mail], feel free to experiment around here, although via your email you mentioned limited knowledge of C++ so this might not be the best choice. There are steps to reproduce in the first comment - basically there's something that Windows taskbar doesn't like about the drag data object we expose when dragging a url bar shortcut onto the taskbar. A number of people have looked at this over the years and so far no one has found a fix.

Comment 43

[Mukhtar Ali]

Hi, my name is Mukhtar Ali and I am currently studying Open-Source Development at Coventry University. For my first bug, I would like to be assigned to this task.

Comment 44

[Mukhtar Ali]

Hi, my name is Mukhtar Ali and I am currently studying Open-Source Development at Coventry University. For my first bug, I would like to be assigned to this task.

Comment 45

[brandon.sherman100]

Hi, my name is Brandon Sherman and I am studying at University of Toronto for my bachelors. I would like to be assigned to this task for my first bug.

Comment 46

[grvi.osource]

Hi, 
Is this bug still exists, can i work on this as my first bug?

Comment 47

[David Teller [:Yoric] - still alive but not very active]

Note to anyone who wishes to work on that bug: yes, you can work on it. The policy is to assign mentored bugs only when someone provides a patch, so don't hesitate to go ahead :)

However, *before* you try and find the correct part of the code to patch, *the first step is to make sure that the bug still exists*.

Comment 48

[Ali]

griv.osource, do you plan to work on this bug or can someone else take it?

Comment 49

[Ali]

I have reproduced this issue on Firefox Quantum 57.0(32-bit), Windows 7 Home Basic Service Pack1.
URL from one Ff window can not be drag-opened into another Ff window minimized in the task bar. Windows emits a sound but shows a crossed-out circle on the minimized bar.

Comment 50

[Syed Ali]

I'm a student from Coventry University and need to fix a few bugs for my coursework. Would you assign me to this?

Comment 51

[Vaishnavi Kaulagi]

Is this still available?

Comment 52

[alex_mayorga]

¡Hola Vaishnavi!

Just tested and the bug still exist on Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0 ID:20190324094708

Updated the flags accordingly.

Feel free to take it!

¡Gracias!
Alex

Comment 53

[Jim Mathies [:jimm]]

(In reply to Vaishnavi Kaulagi from comment #51)

Is this still available?

yes.

If you would like to take this on:

1. see if you can reproduce the bug
2. try to determine the cause. There's some debug logging you can turn on in local builds down in widget (https://searchfox.org/mozilla-central/source/widget/windows/nsWindowDbg.h)

NeedInfo me if you have questions. I don't see random comments posted here.

Comment 54

[Akshat [:baka]]

Hello, I will like to work on this bug. I am still able to reproduce this bug on Ubuntu 20.04. I don't know if that is because of Ubuntu or because this bug still exists. Can someone help me in first properly reproducing this bug and them help me start debugging this bug. I am new to both Mozilla and Open Source.

Comment 55

[Akshat [:baka]]

I have found another bug to work on, If anyone else want to bug, Please work on this, I am cancelling my needinfo flag as well. :)

Comment 56

[Ivan]

Hi, I would like to work on this bug. Can you please assign this to me?

Thanks :)

Comment 57

[BugBot [:suhaib / :marco/ :calixte]]

This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.

Comment 58

[Stephen A Pohl [:spohl]]

Given the history of this bug it does not fit the criteria of a good-first-bug very well anymore. Dropping from the list.

Comment 59

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 3 duplicates.
:spohl, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 60

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 61

[Anna Stigliani]

Attachment: same problem

Thanks from monpancpemi1974.