Open Bug 502457 Opened 15 years ago Updated 2 years ago

menupopup regression, can't display on minimized window

Categories

(Firefox :: Menus, defect)

Product:
Firefox
Component:
Menus
Version:
3.5 Branch
Platform:
x86
Windows XP
Type:
defect

Tracking

()

People

(Reporter: testo.moz, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

opens popup at 0,0 after minimizing the window. Press crtl+alt+p to run.
1.50 KB, application/x-xpinstall
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009060310 Ubuntu/8.10 (intrepid) Firefox/3.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1) Gecko/20090624 Firefox/3.5

I am trying to update/add features to the MinimizeToTray extension https://addons.mozilla.org/en-US/firefox/addon/2110 which I have almost now completed.

My current problem is that when you click on a tray icon, the popup does not show.  After a fair bit of messing with it I have worked out that, it only shows if the window from which it (the popup) originates covers that part of the screen where I want the popup to be. Which is hardly desirable, because I want the windows hidden (I had to disable that to work this out).

Has there been some change in Firefox 3.5 that has lead to this?

I have tried using both openPopupAtScreen & openPopup. The openPopupAtScreen code works perfectly in Firefox 3.

Reproducible: Always
Playing around with DOMi, in "JavaScript object" mode and using "Evaluate JavaScript" and typing "target.openPopupAtScreen(0,0)" in.  I have been able to reproduce my problem consistently.  The popup will only ever show if it overlaps some part of the window from which it comes.
Michael, are you able to see the bug in Firefox 3.0.11 too? If not we would have a regression.

Can you please specify some steps so someone can reproduce without having external dependencies like other add-ons installed? Is there a way to run such a command via the js error console?
The problem does not exist in any other version of Firefox, not 3.0.11 as that has been what I have been working with, and I presume not previous version (the extension has been around since Firefox 1).

I don't know how it could be done from the js error console, at least easily.  You need to get access to a popup, I was using random ones from inside Firefox's popupset element. DOM inspector just seams the easiest way of doing that to me.
Ok, so this would be a regression. We really need a regression range so we can isolate this problem. Michael, would you have time to check the alpha, beta and release candidate versions of Firefox 3.5 to narrow down the range? If you even have more time to run nightly builds it would be perfect to have a day range.

Further it would be helpful when you could give some detailed STR so someone not familiar with DOMi can try to reproduce it. Thanks.
Keywords: regression, regressionwindow-wanted
Version: unspecified → 3.5 Branch
Sorry for the slowish reply, been busy.

I will try and work out when it happened, it will just take a while before I can finish doing it.

Is doing up a simple extension ok?
I guess I should explain the reason I suggested an extension.  The problem with this bug is you need access to some popup that exist in some window.  Outside of DOMi, doing some simple extension is the only way I can think of achieving this, as it needs to run in "chrome".
Sure. We can work out a simpler testcase later. Thanks!
Using the extension as my means of testing bug, the interesting parts of my results where

Extension works fine
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080909032504 Minefield/3.1b1pre

Menu blinks like mad
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080910043000 Minefield/3.1b1pre

Works fine
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080911105329 Minefield/3.1b1pre

Extension breaks
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080912031847 Minefield/3.1b1pre

Still broken
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080913031911 Minefield/3.1b1pre

Is there anything else I can do to help?
(In reply to comment #8)
Thanks Michael!

> Works fine
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre)
> Gecko/20080911105329 Minefield/3.1b1pre
> 
> Extension breaks
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre)
> Gecko/20080912031847 Minefield/3.1b1pre
>
> Is there anything else I can do to help?

Yes, please run those builds again and open "about:buildconfig" in each of them. We need the build identifier to check for possible changesets. It's the link at the top.
Can you also please attach the extension to this bug?
The extension I refer to is not the test case one, that I still plan to create though I have not got around to that yet.  But the MinimizeToTray one.  

You can get that from http://codefisher.org/download/minimize/ what ever is marked as the latest.
Not exactly sure what this build identifier is, but here is a copy and paste from about:buildconfig I don't see the link.

> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre)
> Gecko/20080911105329 Minefield/3.1b1pre

about:buildconfig

Build platform
target
i686-pc-mingw32

Build tools
Compiler 	Version 	Compiler flags
cl 	14.00.50727.762 	-TC -nologo -W3 -Gy -Fd$(PDBFILE)
cl 	14.00.50727.762 	-GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fd$(PDBFILE)

Configure arguments
--enable-application=browser --enable-update-channel=nightly --enable-update-packaging --enable-jemalloc 

> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre)
> Gecko/20080912031847 Minefield/3.1b1pre

about:buildconfig

Build platform
target
i686-pc-mingw32

Build tools
Compiler 	Version 	Compiler flags
cl 	14.00.50727.762 	-TC -nologo -W3 -Gy -Fd$(PDBFILE)
cl 	14.00.50727.762 	-GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fd$(PDBFILE)

Configure arguments
--enable-application=browser --enable-update-channel=nightly --enable-update-packaging --enable-jemalloc 

I got the downloads from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/09/ so what ever was the windows build from those days is what I used.  If that helps identity things.

Last second edit: I opened about:buildconfig in 3.5 and I see the link your talking about now.  Sorry but that is not there in the builds I listed above.  Is there some other way of getting his information?
Can anyone say how to work out what the revisions of those downloads are?  Or is there another place to look to get other builds to test that will tell me their change sets?

I am willing to be a fair amount of work into this bug, if someone can just point me in the right direction.
The bug that caused this regression is bug #435848.
(Attached a debugger, checked the source annotation and found the bug number by this).

As I didn't and still don't expect this to be reverse I worked around this by manipulating the handling of WM_WINDOWPOSCHANGED.
Depends on: 435848
Well I am going to try and get them to change it back.  As I don't think it is a good restriction.

I will have to check WM_WINDOWPOSCHANGED out and see what I can make of it.
The build id is the 14 digit identifier like 20080911105329.

Given the findings from Michael bug 435848 wouldn't fit into the time range. The fix has been checked-in on 080910 but 080911 was working fine. That would mean another patch caused this regression.

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-11+00%3A00%3A00&enddate=2008-09-12+12%3A00%3A00

Michael, are you sure about the given regression range? And we still miss your example xpi.
(In reply to comment #16)
> The build id is the 14 digit identifier like 20080911105329.
> 
> Given the findings from Michael bug 435848 wouldn't fit into the time range.
> The fix has been checked-in on 080910 but 080911 was working fine. That would
> mean another patch caused this regression.

I'm pretty sure that bug #435848 is at least part of the problem.

Actually I found this regression independently, as I'm developing a competing add-on (Minimize To Tray revived).
I back then attached a debugger, found that MayShowPopup returns PR_FALSE when minimized, which is due to http://hg.mozilla.org/releases/mozilla-1.9.1/diff/de4f208c9413/layout/xul/base/src/nsXULPopupManager.cpp#l1.52
I think the comment and code there speak for themselves.
(At least that's what I recall I did).

However I didn't actually expect this new behavior would be something that would be reversed again, so I didn't bother filling a bug but instead implemented a work-around.
(In reply to comment #17)

> However I didn't actually expect this new behavior would be something that
> would be reversed again, so I didn't bother filling a bug but instead
> implemented a work-around.

Since there's a legitimate reason for wanting popups while minimized, you should file a bug so that a solution that meets both requirements can be implemented.
I finished the xpi a few hours before Nils Maier's first post, but in light of it, I thought it would not be needed.  I will post it now.

I maybe I was slightly wrong in the dates (like I was in the original problem description if anyone else noticed), it appears out by one day.  So I will double check again.

In the extension I am about the post, the keyboard short cut to run is ctrl+alt+p.  It minimizes the window then tries to open the popup.
Summary: menupopup regression, can't display outside window → menupopup regression, can't display on minimized window
Confirming based on comment 21. Looks like QA cannot do more. Removing qawanted keyword.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: