Closed Bug 1509847 Opened 6 years ago Closed 5 years ago

Regression: External links open in the wrong windows

Categories

(Firefox :: General, defect, P3)

Product:
Firefox
Component:
General
Version:
64 Branch
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 67
Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox65 --- wontfix
firefox66 --- verified
firefox67 --- verified

People

(Reporter: yurivkhan, Assigned: Gijs)

References

Details

(Keywords: regression)

Attachments

(2 files)

Bug 1509847 - only move minimized windows behind unminimized ones, r?dao
47 bytes, text/x-phabricator-request
lizzard
: approval-mozilla-beta+
Details | Review
Bug 1509847 - don't assume links shouldn't open in minimized windows, r?dao
47 bytes, text/x-phabricator-request
Details | Review 
Versions of software other than Firefox:

* Ubuntu 16.04
* i3 window manager 4.11

The use of i3 may or may not be relevant but i3 is a tiling manager and I think it may internally mark windows minimized when they are not visible. In my reproduction steps below, both Firefox windows and the terminal window belong to the same stacked container, so activating Firefox window A makes Firefox window B invisible; activating the terminal makes both Firefox windows invisible.

To reproduce:

1. Close all Firefox windows.
2. Open a terminal window.
3. Start Firefox with a clean profile.
4. In the initial window, open about:config.
5. Press Ctrl+N to open a new window.
6. In the window opened in step 5, open about:preferences.
7. Switch to the terminal window.
8. Enter the command: $ firefox http://google.com/ . Note in which window it opened.
9. Press Ctrl+W to close the Google tab.
10. Switch to the initial window containing about:config.
11. Switch to the terminal window.
12. Repeat the command: $ firefox http://google.com/ . Note in which window it opened.

Expected behavior:

* In step 8, the new tab opens in the last active window, which was the one with about:preferences (created in step 5).
* In step 12, the new tab opens in the last active window, which was the one with about:config (last activated in step 10).

Observed behavior:

* In both steps, the new tab opens in the same window; or the window in which the tab opens is unpredictable.

Regression range: 

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b38e10e9dcf8008b7f33cc5cef8e695d5a0bf98f&tochange=354003262d9a9091304f2c4b0b8ac7df25cb8fe9

Additional observations, and why this is important for me:

* With the new behavior, Firefox seems to favor currently visible windows when opening external links.
* On my desktop at my job, a typical window layout is:
** One Firefox window on the left monitor, behind a code editor or terminal.
** One or more Firefox windows on the right monitor, behind the mail client.
** One very small Firefox window displaying Slack, always visible.
* As a direct consequence of the above, links from the mail client tend to open in the very small window dedicated to Slack. After that, I have to curse, activate the correct window, and drag the tab. (It’s even worse if I have to switch workspaces and/or stacked windows during the drag.)
Dão, can you take a look?
Blocks: 1489552
Flags: needinfo?(dao+bmo)
Keywords: regression
See Also: 1489552 →
Component: General → Window Management
Product: Firefox → Core
Component: Window Management → General
Product: Core → Firefox
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3

Unfortunately the same issue plagues me for some weeks. I too use i3 window manager (version 4.16) on openSUSE Tumbleweed, with Firefox version 64.0-1.2. However, as the original poster mentions, I don't think it's i3's fault, just that it contributes to making the issue more evident.

Based on the original poster observations -- that of having a Firefox window always visible, makes links open there -- I've tried to replicate that and observed a different behaviour:

  • I've opened 3 Firefox windows, each one on a different workspace;
  • I've opened a terminal on one of those workspaces;
  • I've tried to open a link (via firefox https://google.com/),
  • now if none of the Firefox windows are visible, the links always open in the "first" (in opening order) window;
  • however if I put the terminal and the Firefox window on the same workspace side-by-side (i.e. always visible), the links open in the last "focused" Firefox window (as expected);

I really hope this issue is solved as soon as possible, as it makes Firefox extremely unusable.

Does i3 have a concept of minimization that is more similar to how it works in non-tiling WMs? And/or is there a way to distinguish the i3 case from the "normal" one?

To my knowledge there is no concept of "minimization" in i3; my guess is that windows are just "covered" by other windows.

However I'll send an email to the i3 mailing list, perhaps one of their developers can weigh in.

What is the expectation in the “normal” floating window manager case? That minimizing a window causes external links to open in the most recently active non-minimized one?

(In reply to Yuri Khan from comment #5)

What is the expectation in the “normal” floating window manager case? That minimizing a window causes external links to open in the most recently active non-minimized one?

In the topmost window, yes. We keep a list of windows by z-order, and minimizing a window puts the window at the back of that list. This makes sense in a floating window manager (un-minimizing it will re-insert the window in the list).

In a tiling/stacking window manager such as i3, the z-order notion is still relevant, but only within a stack.

  • If a stack contains two Firefox windows A and B, then activating A should bring it above B in the z-order, and vice versa. Also, activating A in stack S1 should bring it above all Firefox windows in other stacks. This is probably the same mechanic as in the floating wm case.

  • Activating a different application’s window over a Firefox window in the same stack makes the Firefox window invisible, but, conceptually, the Firefox window is not minimized — its title bar is still there, and, from the user’s viewpoint, its window rectangle is still the whole stack client area. Conceptually, that Firefox window is still the topmost Firefox window, even though it is invisible. Cf.: a Firefox window is maximized and active, and then the user activates a different maximized window.

  • Both tiling and floating window managers on X11/GNU/Linux have the concept of workspaces or virtual desktops. Switching from desktop X to desktop Y should probably bring all Firefox windows in Y above all Firefox windows in X in the z-order, while keeping their relative orders within each desktop.

  • i3 also has the notion of a scratchpad workspace. Placing a window into scratchpad does make it totally invisible, no title bar, no implied representation. In this case, it makes sense to drown it to the back of the z-order.

I do not yet know what each of these cases look like, from Firefox’s viewpoint, and whether they are distinguishable. If I were to investigate the interaction between i3 and the Firefox z-order manager, where should I look in Firefox code?

Flags: needinfo?(gijskruitbosch+bugs)

(In reply to :Gijs (he/him) from comment #3)

Does i3 have a concept of minimization that is more similar to how it works in non-tiling WMs? And/or is there a way to distinguish the i3 case from the "normal" one?

I've conveyed this question to i3's mailing list, and the following is the answer from one of the developers.

The bottom-line to my understanding is:

  • i3 never "minimizes" any windows, in fact even if they ask for it, it just re-activates them;
  • in i3 the "stack" order is not the same as "last-focused-to-oldest-focused" order (as per their example "floating" windows can be at the top of the stack, but not focused);

Reply from thread on i3-discuss mailing list:
https://www.freelists.org/post/i3-discuss/Firefox-related-issue-regarding-window-minimization-ie-hiding

indeed, i3 has no concept of minimizing a window. I assume the Z order list they are referencing is the stacking order maintained by the window manager (_NET_CLIENT_LIST_STACKING)? Off the top of my head I'm not sure how i3 chooses that order, but certainly not by a focus history, it's probably just recursing through our internal tree.

I can't think of a good way for FF to distinguish anything here, to be honest. The stacking order and a focus history are fundamentally different concepts (I had a long discussion on GitHub about this just a few days ago https://github.com/i3/i3/issues/3160 ). Going by stacking order is a design decision in FF, but conceptually that's just not the same as the focus order; most window managers probably implement it this way, especially the traditional floating ones, but there's no reason to expect the highest stacked window to be the most recently focused one. For example in i3 floating windows are always higher stacked than tiled windows regardless of focus.

If FF wants to instead go by focus order (which again is a design decision), it'd have to keep this focus order itself as I'm not aware of any specification to implement against here.

That said this is all a bit conjecture as I just assume this is how FF works.

[...] just to emphasize something: I didn't mean to say FF "should" switch to going by focus order. That's of course entirely up to them :-) I just wanted to point out that expecting the stack order to represent the focus order is an incorrect assumption and that in i3 this isn't even possible to "fix" since our floating layer is always on top.

The way i3 reacts to a WM_CHANGE_STATE trying to iconify a window, by the way, is to immediately update the window state to Normal again. This behavior is also fairly new in 4.16, before we simply didn't react to the request. We explicitly reject it now like this because Wine would've run into issues otherwise.

(In reply to Ciprian Dorin Craciun from comment #8)

indeed, i3 has no concept of minimizing a window. I assume the Z order list they are referencing is the stacking order maintained by the window manager (_NET_CLIENT_LIST_STACKING)?

No, we only care about Firefox windows, and they are tracked in JS. It keeps its own list of windows in focus order. The only events that cause anything to happen are:

These are the only things that modify the stack.

So the only explanations I' m seeing here would be that somehow:

If FF wants to instead go by focus order (which again is a design decision), it'd have to keep this focus order itself as I'm not aware of any specification to implement against here.

We're trying to do exactly this, AFAICT. The activate JS event is sent based on the gtk containerfocusin event, see https://searchfox.org/mozilla-central/rev/152993fa346c8fd9296e4cd6622234a664f53341/widget/gtk/nsWindow.cpp#2666 .

Flags: needinfo?(gijskruitbosch+bugs)

As another person affected by this new behaviour, I can add that I've done some experiments on an empty workspace with no other firefox instances open. It's really weird the way it works, and I've not been able to develop a reliable mental model to predict which unmapped firefox window will choose to handle a new window event.

Cf. https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1810902/comments/3

Some further discussion also here, fwiw:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1810902

My copy of ubuntu has i3 version 4.14.1 - I'm aware it's a little old but it's what I have atm. Doing some debugging there, it seems when the user switches away from the window to another window in the stack, i3 causes us to get window sizemode changes that indicate that window is minimized. That's the cause of the issue. In the case from comment #0, if activating the terminal with Fx windows A and B, if B was the last focused Fx window, we get a minimized sizemode event for it and put it at the back of the focused list. As a result, the next link will open in window A. When you go back to terminal from window A, the same thing happens to window A and so the next link will open in window B, etc.

(In reply to Ciprian Dorin Craciun from comment #8)

The bottom-line to my understanding is:

  • i3 never "minimizes" any windows, in fact even if they ask for it, it just re-activates them;

So, this doesn't seem to be true. When switching from the Firefox window in a stack to a terminal window, we hit this code:

https://searchfox.org/mozilla-central/rev/152993fa346c8fd9296e4cd6622234a664f53341/widget/gtk/nsWindow.cpp#2949-2951

void nsWindow::OnWindowStateEvent(GtkWidget *aWidget,
                                  GdkEventWindowState *aEvent) {


  if (aEvent->new_window_state & GDK_WINDOW_STATE_ICONIFIED) {
    LOG(("\tIconified\n"));
    mSizeState = nsSizeMode_Minimized;

(which you can see for yourself when running Firefox with env var MOZ_LOG_MODULES=Widget:5 )

Mike/Dão, why does the current code rely on sizemode changes (and put things all the way at the back in that case) instead of using e.g. deactivate events, and assuming that until/unless another window is activated, the previous topmost window is still the topmost window?

Flags: needinfo?(mdeboer)

(In reply to :Gijs (he/him) from comment #11)

  • i3 never "minimizes" any windows, in fact even if they ask for it, it just re-activates them;

So, this doesn't seem to be true. When switching from the Firefox window in a stack to a terminal window, we hit this code:

According to the i3 developers:

[...] if this issue is somehow specific to
tabbed/stacked containers, one additional thing worth pointing out is
that i3 sets _NET_WM_STATE_HIDDEN on windows which are inside a
tabbed/stacked containers but currently not focused within it. Browsers
usually put such windows into sone kind of performance-saving mode, so I
don't know if this could also interfere with it.

(In reply to :Gijs (he/him) from comment #12)

Mike/Dão, why does the current code rely on sizemode changes (and put things all the way at the back in that case) instead of using e.g. deactivate events, and assuming that until/unless another window is activated, the previous topmost window is still the topmost window?

This goes back to bug 1034036. I don't think it's really needed and could just be dropped.

Blocks: 1034036
Flags: needinfo?(dao+bmo)

IIRC, this was necessary for some OS - I think it was Windows, but might just as well have been OSX - that didn't fire a 'deactivate' event when a window got minimized. I needed to specifically capture it this way. Now that would've been captured in the review comments of earlier revisions, but that's lost now.
Only option left, unfortunately, is to yank it out and see which world crumbles.

Flags: needinfo?(mdeboer)

(In reply to Mike de Boer [:mikedeboer] from comment #15)

IIRC, this was necessary for some OS - I think it was Windows, but might just as well have been OSX - that didn't fire a 'deactivate' event when a window got minimized.

It's not clear to me that we need to somehow handle that case in the first place, i.e. that we need to move minimized windows to the end of the list rather than just moving any activated window to the start.

I guess SessionStore wants to restore minimized windows last, but it also keeps track of sizemodes separately, so I don't think this needs to be baked into BrowserWindowTracker's ordered window list.

(In reply to Dão Gottwald [::dao] from comment #16)

(In reply to Mike de Boer [:mikedeboer] from comment #15)

IIRC, this was necessary for some OS - I think it was Windows, but might just as well have been OSX - that didn't fire a 'deactivate' event when a window got minimized.

It's not clear to me that we need to somehow handle that case in the first place, i.e. that we need to move minimized windows to the end of the list rather than just moving any activated window to the start.

Well, given something like:

  1. open 2 fx windows (A and B)
  2. focus another app
  3. minimize window A, focus returns to other app
  4. from the other app, click link

you'd want the link to open in B. Pretty sure that the code for that just asks BrowserWindowTracker for the 'top' window; we wouldn't want that to be restoring the minimized window.

I think the way around this is to ignore minimized windows when BWT gets asked about the top window, and "manually" sort them last when it gets asked for the ordered set of windows, rather than listening for the minimize events and then putting the windows at the back.

Alternatively, we could make the minimize sizemodechange event move the window to after the last non-minimized window (instead of always putting it all the way at the back, which causes the reordering which is causing this bug).

Dão, both of these solutions seem relatively simple to implement. I'm happy to write the patch - does either of these sound preferable to you?

Flags: needinfo?(dao+bmo)

Remember, though, that in the context of a tiling window manager, there is no concept of "top", only last focused.

Even FFM (focus-follows-mouse) in a non-tiling window manager makes this subtle. Suppose I have an xterm partially covering a firefox window. I'm copying information between them. Neither is the top-most window. In the xterm, I request that firefox displays a page. I'd expect it to display in the firefox window with which I've been interacting. But some other firefox window may be further up in the z-order, though perhaps completely obscured or simply not where I've been looking. That would be quite unexpected as well.

(In reply to Jeff Abrahamson from comment #19)

Remember, though, that in the context of a tiling window manager, there is no concept of "top", only last focused.

Sure, getTopWindow is simply what the method is named today; in practice it should be returning the last focused (non-minimized) window, ie the top element in the stack of windows ordered by last-focused. Naming (esp. accuracy in conflict with brevity) is the hardest problem in computer science etc. etc.

(In reply to :Gijs (he/him) from comment #18)

(In reply to Dão Gottwald [::dao] from comment #16)

(In reply to Mike de Boer [:mikedeboer] from comment #15)

IIRC, this was necessary for some OS - I think it was Windows, but might just as well have been OSX - that didn't fire a 'deactivate' event when a window got minimized.

It's not clear to me that we need to somehow handle that case in the first place, i.e. that we need to move minimized windows to the end of the list rather than just moving any activated window to the start.

Well, given something like:

  1. open 2 fx windows (A and B)
  2. focus another app
  3. minimize window A, focus returns to other app
  4. from the other app, click link

you'd want the link to open in B.

Not necessarily. If you actually used window A in step 3, minimizing it could just be a way to return to the other app, and it's not clear that the user will expect links to open in window B, which they might have forgotten about while using A, and it could be covered by other stuff or even have been minimized before A was.

I think the way around this is to ignore minimized windows when BWT gets asked about the top window, and "manually" sort them last when it gets asked for the ordered set of windows, rather than listening for the minimize events and then putting the windows at the back.

Alternatively, we could make the minimize sizemodechange event move the window to after the last non-minimized window (instead of always putting it all the way at the back, which causes the reordering which is causing this bug).

Dão, both of these solutions seem relatively simple to implement. I'm happy to write the patch - does either of these sound preferable to you?

Not sure, but I'd point out that getTopWindow must not completely ignore minimized windows, because there might be no restored or maximized one.

Flags: needinfo?(dao+bmo)

So I've attached two possible patches. The first one is smaller, fixes this bug, and doesn't fundamentally change that we listen for and act on minimize events - it just changes how we do so, ensuring we preserve last focused order among minimized windows.

The second one takes some of the earlier comments and runs with them, ie it removes minimize handling entirely.

Certainly if we want to uplift anything, I think we should use the first patch. Esp. on mac, IMHO it is somewhat surprising to have a minimized window come back to open links in it.

However, long term, I don't feel super strongly about which one of these to use. The common case is still that focus goes from one window to another and that'll track focus. The minimize handling is somewhat of a detail (obviously, not entirely, esp. in the context of this bug, but either patch will do to fix this bug, AIUI).

Dão, let me know if landing the first and uplifting it to beta, and/or landing the second (maybe both, one after the other, on central) make sense to you.

Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/4f44987ada94
only move minimized windows behind unminimized ones, r=dao

https://hg.mozilla.org/mozilla-central/rev/4f44987ada94

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox67: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67

Could one of you confirm that this issue has been addressed on Nightly (https://nightly.mozilla.org/ ; make sure you close any running Firefoxes before trying to launch nightly).

Flags: needinfo?(yurivkhan)
Flags: needinfo?(jeff)
Flags: needinfo?(ciprian.craciun)

(In reply to :Gijs (he/him) from comment #27)

Could one of you confirm that this issue has been addressed on Nightly (https://nightly.mozilla.org/ ; make sure you close any running Firefoxes before trying to launch nightly).

I can confirm that the latest nightly does behave as expected, i.e. the links open in the last focused Firefox window, even if it is not visible.

Thanks!

Flags: needinfo?(ciprian.craciun)

Thanks!

Status: RESOLVED → VERIFIED
status-firefox67: fixed → verified
Flags: needinfo?(yurivkhan)
Flags: needinfo?(jeff)

Comment on attachment 9042551 [details]
Bug 1509847 - only move minimized windows behind unminimized ones, r?dao

Beta/Release Uplift Approval Request

Feature/Bug causing the regression

Bug 1489552

User impact if declined

Firefox stops opening links in the right window when using i3 or other tiling window managers on Linux

Is this code covered by automated tests?

Yes

Has the fix been verified in Nightly?

Yes

Needs manual test from QE?

Yes

If yes, steps to reproduce

(yes for beta verification - See comment #0)

List of other uplifts needed

n/a

Risk to taking this patch

Low

Why is the change risky/not risky? (and alternatives if risky)

This is a minimal fix that makes a small change to how Firefox frontend considers the ordering of windows that are minimized by the user.

String changes made/needed

nope

Attachment #9042551 - Flags: approval-mozilla-beta?
Depends on: 1529577

Nope, not confirming. The scenario described at the bottom of my original post is still broken.

Simplified description for people with one monitor:

  • i3.
  • The workspace is split horizontally into left and right halves. The left half hosts Firefox window A. The right half is a stacked layout, with Firefox window B and a terminal emulator over it. Window B was the last active.
  • In terminal: firefox http://google.com/

Expected: New tab in window B, most recently active Firefox window.

Observed: New tab in window A, the one currently visible.

(In reply to Yuri Khan from comment #31)

Nope, not confirming. The scenario described at the bottom of my original post is still broken.

Simplified description for people with one monitor:

  • i3.
  • The workspace is split horizontally into left and right halves. The left half hosts Firefox window A. The right half is a stacked layout, with Firefox window B and a terminal emulator over it.

How do I actually do this in i3? I spent hours trying to figure this out for even the initial fix.

Flags: needinfo?(yurivkhan)

(In reply to Yuri Khan from comment #31)

Nope, not confirming. The scenario described at the bottom of my original post is still broken.

Simplified description for people with one monitor:

  • i3.
  • The workspace is split horizontally into left and right halves. The left half hosts Firefox window A. The right half is a stacked layout, with Firefox window B and a terminal emulator over it. Window B was the last active.
  • In terminal: firefox http://google.com/

Expected: New tab in window B, most recently active Firefox window.

Observed: New tab in window A, the one currently visible.

I can confirm Yuri's "not confirming" issue. Indeed if I follow his steps, the link opens in the wrong window.

However this is strange, because if the B Firefox window is in fact on a different workspace (as opposed "stacked" or "tabbed" together with the terminal), even if on the workspace with the terminal there is an open and visible Firefox window A with the split layout, if I switch between the workspaces so that the Firefox on the other workspace (i.e. B) is the last focused one, then the link correctly opens in that one.

Therefore it seems that the issue remains only in the case of "stacked" or "tabbed" layouts in i3.

Can I provide perhaps more information about the windows status when "staked"?

(In reply to :Gijs (he/him) from comment #32)

(In reply to Yuri Khan from comment #31)

Nope, not confirming. The scenario described at the bottom of my original post is still broken.

Simplified description for people with one monitor:

  • i3.
  • The workspace is split horizontally into left and right halves. The left half hosts Firefox window A. The right half is a stacked layout, with Firefox window B and a terminal emulator over it.

How do I actually do this in i3? I spent hours trying to figure this out for even the initial fix.

You open a terminal, and two Firefox windows. Select one of the two Firefox windows and press Mod1+J (i.e. Alt+J), according to: https://i3wm.org/docs/userguide.html#_default_keybindings

This should give you one visible Firefox window, and on the other side of the monitor, one terminal and the other Firefox window sharing the same half, only one of them being visible at a time.

(In reply to :Gijs (he/him) from comment #32)

Simplified description for people with one monitor:

  • i3.
  • The workspace is split horizontally into left and right halves. The left half hosts Firefox window A. The right half is a stacked layout, with Firefox window B and a terminal emulator over it.

How do I actually do this in i3? I spent hours trying to figure this out for even the initial fix.

From a clean session, out-of-the-box i3 config (Mod1 is normally Alt):

  • Start a terminal (Mod1+Return). You have a terminal spanning the whole desktop.
  • Start Firefox from said terminal ($ firefox &). Now you have two windows side by side; terminal and Firefox window A.
  • In the Firefox window A, press Ctrl+n. Now you have three windows side by side: terminal, Firefox A, Firefox B.
  • Switch to the terminal window by whatever means. Mouse is okay. Mod1+Left twice is another way.
  • Split the terminal window vertically (Mod1+v) or horizontally (Mod1+h). Visually, the bottom or right border of the terminal window lights up.
  • Switch to the Firefox window B. Again, mouse is fine, Mod1+Right twice is another way.
  • Move the Firefox window B into the split container with the terminal (Mod1+Shift+Left twice). Now you have three windows in a nested split layout: terminal on top left, Firefox B on bottom left, and Firefox A on the right.
  • Switch the left half to stacked layout (Mod1+s). Now you have the desired layout: stack of terminal and Firefox B on the left, and Firefox A on the right.
  • Use Mod1+Left and Mod1+Right to switch between screen halves, and Mod1+Up and Mod1+Down to switch between stacked windows. Alternatively, click on window title bars to activate them.

(I have actually tested this recipe in Xephyr started as Xephyr -br -ac -noreset -screen 1024x800 :1; DISPLAY=:1 i3 -c /etc/i3/config. That starts a separate X session in a window, without ruining your working desktop and/or personal i3 config.)

OK, thanks everyone. I can confirm that the issue with split screens (where one window stays visible/unminimized, but never gets focused, and the other one (though last focused and thus expected location for new tabs) is minimized as a consequence of being in i3's stacked/tabbed view with a terminal) is fixed by the second patch, but not by the first.

I just landed the second patch in bug 1529577 (in fact, before the comments here that said this wasn't completely fixed...). That patch is more invasive (it removes minimization handling completely, relying only on window activation itself) and will affect mac/windows/non-tiling-linux-wms more than the minimal patch I landed here. I split them up so we can keep track of them separately.

Given that the minimal patch that is already in nightly does improve things a bit (e.g. the workspace thing that Ciprian mentioned), I'll keep the beta uplift request for that. I'll CC you on 1529577 and ping you once there's a nightly build with that patch available to check that it works for you.

Thanks again for the help in diagnosing this.

Flags: needinfo?(yurivkhan)

Comment on attachment 9042551 [details]
Bug 1509847 - only move minimized windows behind unminimized ones, r?dao

Fix for regression from 64, has test coverage, verified in nightly.
OK for uplift for beta 11.

Attachment #9042551 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
Whiteboard: [qa-triaged]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0
Build ID: 20190225143245

Verified as fixed on Beta 11 using Ubuntu 16.04 LTS.

status-firefox66: fixed → verified
Flags: qe-verify+
Whiteboard: [qa-triaged]
See Also: → 658660
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: