Closed Bug 1736792 Opened 4 years ago Closed 4 years ago

Pop-up window drawn in the wrong place

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1736949
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- unaffected
firefox93 --- unaffected
firefox94 --- unaffected
firefox95 --- affected

People

(Reporter: darktrojan, Unassigned)

References

(Regression)

Details

(Keywords: regression)

After bug 1736068 pop-up windows are now drawn in the top-left-hand corner of the screen, though they are actually in the middle (if opened with centerscreen) or elsewhere if moved around. The rectangle where the window really is just displays what was there at the time of opening.

I went back to the nightly before bug 1736068 and it didn't happen there so I'm fairly sure it has to be the cause.

Here's the simple test case I'm using again:

Services.ww.openWindow(null, "about:mozilla", "_blank", "popup,centerscreen,width=640,height=480", Services.ww)
Flags: needinfo?(stransky)

This example is wrong:

Services.ww.openWindow(null, "about:mozilla", "_blank", "popup,centerscreen,width=640,height=480", Services.ww)

You're opening a popup window but without any parent which is incorrect (popups are positioned relatively to parent window). Also the popup position is not specified, you set only size.

I think you need to figure out your need and the select proper window type for it.

Flags: needinfo?(stransky)

Ok, I see the 'centerscreen' param but it's still popup without parent. You should use modal popup and select correct parent window.

Our need is a window before any others are open, because we're doing migration things that need to happen before the rest of the program starts. I wouldn't use the popup type except that I'd prefer the window to not be closable because that will leave the user with no indication of what is going on.

In such case please use regular toplevel window without decorations.

(In reply to Geoff Lankow (:darktrojan) from comment #3)

I wouldn't use the popup type except that I'd prefer the window to not be closable because that will leave the user with no indication of what is going on.

That's interesting - does it behave the same on all platforms? Is the popup without parent persistent everywhere or is that just Linux specific?

In such case please use regular toplevel window without decorations.

How do I do that? I've never found a way, or I wouldn't be trying to do it this way.

That's interesting - does it behave the same on all platforms? Is the popup without parent persistent everywhere or is that just Linux specific?

Not sure I follow. What I'm trying to do is the same everywhere, if that's what you're asking.

(In reply to Geoff Lankow (:darktrojan) from comment #6)

In such case please use regular toplevel window without decorations.

How do I do that? I've never found a way, or I wouldn't be trying to do it this way.

That's interesting - does it behave the same on all platforms? Is the popup without parent persistent everywhere or is that just Linux specific?

Not sure I follow. What I'm trying to do is the same everywhere, if that's what you're asking.

Yes, I understand you. You need a panel which is drawn at center of the screen and user can't close it (needs to be closed by application only).
But how do you end up with the

Services.ww.openWindow(null, "about:mozilla", "_blank", "popup,centerscreen,width=640,height=480", Services.ww)

example? Is that documented somehow that this specific config produces such window? Or did you find that by some experiment?
I'm asking because I need to understand how is that supposed to work, it looks like just a bug/window missconfiguration to me but maybe it's a documented way how to create such window and we need to implement such specific setup in widget code.

And does the example above works as expected on Mac/Windows? Is Linux the only broken platform here?

I see. It's not documented, I figured it out by trawling through the features in nsWindowWatcher.cpp. (In fact I'm not aware of any good documentation on the features outside of those usable by web stuff, which is how I ended up looking at the code. Also the IDL says last argument can be null except doing that crashes, but I digress…) It does work fine in the other platforms, or did last time I checked.

Sorry I'm wasting your time on this. I had exactly what I thought I wanted and was about to get it reviewed and landed, and then it broke.

Okay, if Linux is the only non-working platform here we may 'fix' that.

Hm, I think you need to use a toplevel window anyway. It may be confusing if you create a phantom window which isn't attached to any application and can't be closed. If you create a toplevel window you can use handlers attached to 'close' signal. When such signal comes you can ask user if the the migration needs to be aborted and clean up. It's much better than workaround it by a persistent window.

Set release status flags based on info from the regressing bug 1736068

status-firefox93: --- → unaffected
status-firefox94: --- → unaffected
status-firefox95: --- → affected
status-firefox-esr78: --- → unaffected
status-firefox-esr91: --- → unaffected

Bug 1736949 isn't fixing this too, or?

(In reply to Magnus Melin [:mkmelin] from comment #13)

Bug 1736949 isn't fixing this too, or?

I think that's a different issue.

It looks like the same after all.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.