1498973 - Waking up from sleep / switching to tablet mode shows a sticky address bar panel, when Firefox is the default browser

Status: VERIFIED FIXED

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

Description

[joviedo]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0

Steps to reproduce:

Microsoft Windows 10 and Surface

1.- Open Firefox
2.- Change Mode Tablet (ON)
3.- Change Mode Laptop (OFF)
4.- Problem with the address bar


Actual results:

the address bar is visible and does not return to its original state (without showing the address history)


Expected results:

It must return to its original state (only show above) without having a half screen with the address history

Comment 1

[Marco Bonardo [:mak]]

Dao, do you know where we manage tablet mode/Surface bugs? I'm not sure whether this is effectively Address Bar, Theme or Win32 Widgets

Comment 2

[Dão Gottwald [:dao]]

I'm not entirely sure I understand the actual and expected results, but it sounds like a problem in front-end application logic, so neither widget nor theme.

Comment 3

[joviedo]

I have uploaded a video with the error process

https://www.youtube.com/watch?v=NLaC_zANj7c

Comment 4

[Marco Bonardo [:mak]]

Ah I see, when switching tablet mode the address bar panel opens, but the underlying code doesn't know about that and it gets out of sync. It doesn't seems to be persistent though, typing in the input box seems to close it.
It may be a widget or frontend code problem, I'm not sure why a panel would get suddenly opened just by switching mode :/

Comment 6

[mikaaa92]

Attachment: Display bug when switching from win10 tablet mode to desktop mode

Same bug on my HP Spectre 15 on Windows 10 Pro 1809, Firefox 63.0.1.
When i use Firefox in tablet mode then when i switch on desktop mode, the address bar don't want to disappears although i type or click in another place. The quickest solution is to close Firefox.

Comment 7

[u628287]

Reproducible on a Surface Go, Windows 10 Home 1809, Firefox 63.0.1
Address bar and notification dialogue (ex. remember password, remember autoplay, etc.) both appear after exiting tablet mode. The notification bubble only appears when exiting tablet mode if it had appeared earlier in the session. Unfortunately do to the infrequency of the notification bubble the fastest way to close it is to restart Firefox. Address bar can be dismissed by navigating to a new webpage.

Comment 8

[u628287]

Also reproduces on FireFox 65.0a1 (2018-11-14) Nightly.

Comment 9

[Mark]

I can also reproduce this on a Surface Pro 5, Windows 10 Pro 1809, Firefox 63.0.3. This actually happens with multiple UI elements, not just the address bar. This happens with not only the address bar, but also the hamburger menu to the right and anytime a webpage asks for permissions. The UI elements seem to artifact if opened while you toggle tablet mode. In the screenshot below, I read an article earlier on ZDNet's site, and the site asked for the notifications permission. The ghosted UI element is still there from earlier since I switched to tablet mode while reading. Even though I initially dismissed the element on the site, it still artifacts. The artifact can't be dismissed or interacted with unless I close Firefox.

https://cl.ly/666e8f621c2a/FF_UI_Artifacts.png

Comment 11

[xracoonx]

Are you sure the importance of the ticket reflects how annoying it is to the standard user?(In reply to Marco Bonardo [::mak] from comment #4)
> Ah I see, when switching tablet mode the address bar panel opens, but the
> underlying code doesn't know about that and it gets out of sync. It doesn't
> seems to be persistent though, typing in the input box seems to close it.
> It may be a widget or frontend code problem, I'm not sure why a panel would
> get suddenly opened just by switching mode :/

Given that there are other overlays, like password manager, that cannot be easily dismissed and forces normal users to restart Firefox independently, are you sure the importance is set correctly?

Comment 12

[Marco Bonardo [:mak]]

I don't have a device where I can even try reproducing this, and I think it's the same for other members of the Address Bar team, P5 means we'll accept patches by the community. This blocks bug 1170714 that is a platform bug, this is indeed likely a widget bug for which this team can't do much (especially without a device to test it). There are many other bugs tracked in that bug and likely some of those are related, or the same.

Comment 13

[xracoonx]

Thanks for the quick reply.

(In reply to Marco Bonardo [::mak] from comment #12)
> I don't have a device where I can even try reproducing this, and I think
> it's the same for other members of the Address Bar team, P5 means we'll
> accept patches by the community.\

Not sure I understand correctly. Are you saying that no one has a computer running Windows 10? That's unfortunate. 

By the way, if someone ever gets hands on a Windows 10 computer and wants to reproduce, in contrast to the description, I have to first type something into the address bar for the problem to show. (It's like Firefox is showing whatever overlay from the address bar was last shown or so.)

> This blocks bug 1170714 that is a platform
> bug, this is indeed likely a widget bug for which this team can't do much
> (especially without a device to test it). There are many other bugs tracked
> in that bug and likely some of those are related, or the same.

It started only recently on Windows 10. Are you interested in a bisect?

Comment 14

[Marco Bonardo [:mak]]

Sure, a regression range would be useful.
And you are right, apparently it's not necessary to have a touch screen, so we could reproduce.

Comment 15

[xracoonx]

Okay, that's maybe interesting. I wasn't able to reproduce the bug with moz-regression. Though I see it with both of my local stable and nightly versions (and in Safe Mode as well).

Comment 16

[xracoonx]

This bug is really annoying... Since I wasn't able to find the regression window, I am wondering whether this might have to do with some Windows 10 update. I am on 1809 17763.134. joviedo, are you on 1809 as well?

Comment 17

[Dão Gottwald [:dao]]

I managed to reproduce this a few times, but it's really hard for me to do so consistently. Any chance you can expand the steps to reproduce? E.g. do you have session restore enabled? Do you have about:home / about:newtab or some other page loaded? Is focus in the location bar? Do you type something before entering tablet mode? Do you enter tablet mode by mouse or touch? Is the window maximized? Are there other non-Firefox windows open? Can you reproduce with Nightly?

Comment 18

[xracoonx]

(In reply to Dão Gottwald [::dao] from comment #17)
> I managed to reproduce this a few times, but it's really hard for me to do
> so consistently. Any chance you can expand the steps to reproduce? E.g. do
> you have session restore enabled?

No.

> Do you have about:home / about:newtab or some other page loaded? 

No.

> Is focus in the location bar?

No.

> Do you type something before entering tablet mode?

Yes, I have done something, like typing in the address bar that opens its drop down list. But it can be closed and the address bar cleared again. One thing I noticed: if I have a new Firefox window open but not yet opened the address bar menu, then the previous window (that had the drop down menu opened before) is broad to front as well.

> Do you enter tablet mode by mouse or touch? 

Doesn't matter. 

>Is the window maximized? 

Doesn't matter. Though the drop down menu that gets shown will be exactly like it was shown last and now how it would show according to the current window dimensions.

> Are there other non-Firefox windows open?

Doesn't matter.

> Can you reproduce with Nightly?

Yes.

Comment 19

[Dão Gottwald [:dao]]

(In reply to xracoonx from comment #18)
> > Do you have about:home / about:newtab or some other page loaded? 
> 
> No.

That was an either/or question. :)

Comment 20

[xracoonx]

(In reply to Dão Gottwald [::dao] from comment #19)
> (In reply to xracoonx from comment #18)
> > > Do you have about:home / about:newtab or some other page loaded? 
> > 
> > No.
> 
> That was an either/or question. :)

I see. There is no particular page loaded.

Comment 21

[Dão Gottwald [:dao]]

Meaning... the default home page? about:blank?

Comment 22

[xracoonx]

Meaning the problem occurs with any of the pages you mentioned loaded but also without any of those loaded.

Comment 23

[Marco Bonardo [:mak]]

I can reproduce with the steps in comment 0, and the bug seems more common than expected, so bumping up. Hopefully I can find some time to debug it in the next weeks.

Comment 24

[Marco Bonardo [:mak]]

I made a few experiments to reproduce this, I can only reproduce the bug in official nightly builds, I cannot reproduce it from my own builds, nor optimized nor debug. It may be related to PGO, maybe a race condition that happens at a different time. This may complicate debugging if it ends up being something in platform.

Comment 25

[Marco Bonardo [:mak]]

The other thing I can tell is that it's not our bindings opening the panel, I added a bunch of js breakpoints on the bindings and none was hit, while they are hit on a normal open. I don't even see a popupshowing event afaict, that I see for a normal opening.

I suspect this happens at the platform level, considered not even events are fired. The problem is that we need a way to reproduce it with a custom build to debug it.

Comment 26

[xracoonx]

(In reply to Marco Bonardo [::mak] (Away 24 Dec - 2 Jan) from comment #23)
> I can reproduce with the steps in comment 0, and the bug seems more common
> than expected, so bumping up. Hopefully I can find some time to debug it in
> the next weeks.

That would be great. I am committed to using Firefox on Windows but I fear that others might start to switch. Especially with the Surface Pro which does not always have the tightest connection between the keyboard and tablet switch between desktop and tablet mode happens regularly when lifting it.

Daniel

Comment 28

[Marco Bonardo [:mak]]

Neil, you are the person with the deepest knowledge in menu and frames, so as a last resort I'm also trying to ask you whether you have any idea/thought about this behavior.
I couldn't find good STR to reproduce in a new profile or from a custom build (I also tried a custom PGO build), that makes debugging this quite difficult. I don't see events (showing/shown) when this happens too.

Comment 29

[Neil Deakin]

From the description above, it sounds like Windows is doing something with the native windows that causes the popup to reshow. If we could reproduce better, a first step would be to determine whether ShowWindow is being called, or we are receiving a message that the popup is being reshown, to narrow down whether we are doing something wrong here.

Comment 30

[Marco Bonardo [:mak]]

I wonder if we could release a Nightly with some additional logging for this.

Comment 31

[Brent]

If it makes a differenve, I can reproduce it every time. And as xracoonx said, I’m also committed to using Firefox as my primary browser, so anything I can do to help please let me know! Thanks for your help everyone.

Comment 32

[Brent]

Also, My system is not a Surface, it is a Dell Inspiron 11 3147

Comment 33

[Jaagup Irve]

This is highly likely a problem that starts with upgrade to Windows 10 version 1809.

On a hunch I tested a bit:

version 1803 - Firefox works as intended - confirming on 2 machines.
version 1809 - reproduces bug; confirming on 2 different machines.

It is definetly related to 1809 upgrade since one of the machines that didn't have the problem started exhibiting the behaviour after I did the upgrade to see if Windows version was part of the equation.

Comment 34

[Marco Bonardo [:mak]]

I fear I'm not the right person to go after this, since I cannot debug it. Someone with more experience with native windows management is required to try to add logging and figure out what's up.

Comment 35

[Jaagup Irve]

One more comment. Not only address bar gets re-displayed, but also the password prompt, web-page properties. But not the burger menu. What whoever takes this one on might want to look what is the difference.

I am attaching a screenshot of those two being displayed (removed the address bar by typing)

Comment 36

[Jaagup Irve]

Attachment: Other floating elements that get displayed by exiting the tablet mode on Windows 10 version 1809

Comment 37

[xracoonx]

(In reply to Jaagup Irve from comment #35)

One more comment. Not only address bar gets re-displayed, but also the password prompt, web-page properties. But not the burger menu. What whoever takes this one on might want to look what is the difference.

For me the burger menu gets stuck from time to time as well. So, I don't think looking into the difference there will be of much help.

Comment 40

[dope]

hey i have the same bug. on windows 10, 64.0.2 (64-bit).

Comment 41

[xracoonx]

FYI, the bug does not appear in Tor (Firefox 60.4esr).

Comment 42

[Marco Bonardo [:mak]]

(In reply to Neil Deakin from comment #29)

From the description above, it sounds like Windows is doing something with
the native windows that causes the popup to reshow. If we could reproduce
better, a first step would be to determine whether ShowWindow is being
called, or we are receiving a message that the popup is being reshown, to
narrow down whether we are doing something wrong here.

Neil, I found a way to reproduce this easily, it basically requires the firefox build to be set as the default browser in Windows 10. If the build is not set as the default browser it doesn't reproduce. This allows also to use a debug build.
I suspect Windows sends some additional notification for the default browser window, maybe for some Edge behavior. So far I saw a WM_SETFOCUS message and I see the focus manager doing some looking for descendant elements just before the popup is shown again. Unfortunately I don't know this code well enough to look for suspicious flags.

Basically the updated STR are:

1. Set the build as the default browser
2. launch firefox
3. type something in the address bar, so the popup is shown at least once
4. dismiss the popup (esc or click elsewhere)
5. from the Windows 10 notification pane switch on and off tablet mode
6. The address bar popup is shown and it's sticky until you type again in the address bar

Comment 44

[marco smith]

running firefox v 64.2 on windows 10 surface pro 3 and it is still happening.

Comment 45

[marco smith]

on v 65 and it is still happening (sorry for the spam,i dont know how to edit comments)

Comment 52

[xracoonx]

I suggest to raise the importance of this bug. I guess, there will be more and more people having this problem now that Microsoft decided to automatically update Windows 10 to 1809. I fear that people will become annoyed and abandon Firefox.

Comment 53

[Neil Deakin]

It looks like an extra WM_WINDOWPOSCHANGING and WM_SHOWWINDOW message followed by some activation messages are being sent to the popup window in this case. Here is a log of the messages received after switching out of tablet mode:

HWND [wParam lParam] message

1. 000A0AD8 [0 b7e0a8] WM_SETTINGSCHANGE
2. 00130A2E [0 b7e0a8] WM_SETTINGSCHANGE
3. 000A0AF4 [0 b7e0a8] WM_SETTINGSCHANGE
4. 000A0AD8 [0 efee9c] WM_WINDOWPOSCHANGING (WINDOWPOS.flags is 13)
5. 00130A2E [0 efee9c] WM_WINDOWPOSCHANGING (WINDOWPOS.flags is 8020)
6. 00130A2E [1 efee74] WM_NCCALCSIZE
7. 00130A2E [1 0] WM_NCPAINT
8. 00130A2E [9301119f 0] WM_ERASEBKGND
9. 00130A2E [0 efee9c] WM_WINDOWPOSCHANGED
10. 000A0AD8 [0 efee9c] WM_WINDOWPOSCHANGING (WINDOWPOS.flags is 4014)
11. 000A0AD8 [1 0] WM_SHOWWINDOW
12. 000A0AD8 [0 efee9c] WM_WINDOWPOSCHANGING
13. 00130A2E [0 efee9c] WM_WINDOWPOSCHANGING
14. 00130A2E [0 a0ad8] WM_NCACTIVATE
15. 00130A2E [0 a0ad8] WM_ACTIVATE
    ...

In a working build, line 10 and on do not occur, and other painting and mouse related messages are sent as normal.

I'm not sure what specifically triggers the difference, but it has something to do with being the default browser. Running with '-setDefaultBrowser' is enough to trigger the issue on a build that doesn't have this issue, but resetting the default browser afterwards does not make the issue go away again. Moving the build to a different directory does make the issue disappear again.

Comment 54

[Neil Deakin]

Note that in the log in the previous comment, '000A0AD8' is the autocomplete dropdown window and '00130A2E' is the browser window.

Comment 55

[marco smith]

firefox is not the default browser on my computer and i have this issue

Comment 56

[marco smith]

(In reply to Neil Deakin from comment #53)

It looks like an extra WM_WINDOWPOSCHANGING and WM_SHOWWINDOW message followed by some activation messages are being sent to the popup window in this case. Here is a log of the messages received after switching out of tablet mode:

HWND [wParam lParam] message

1. 000A0AD8 [0 b7e0a8] WM_SETTINGSCHANGE
2. 00130A2E [0 b7e0a8] WM_SETTINGSCHANGE
3. 000A0AF4 [0 b7e0a8] WM_SETTINGSCHANGE
4. 000A0AD8 [0 efee9c] WM_WINDOWPOSCHANGING (WINDOWPOS.flags is 13)
5. 00130A2E [0 efee9c] WM_WINDOWPOSCHANGING (WINDOWPOS.flags is 8020)
6. 00130A2E [1 efee74] WM_NCCALCSIZE
7. 00130A2E [1 0] WM_NCPAINT
8. 00130A2E [9301119f 0] WM_ERASEBKGND
9. 00130A2E [0 efee9c] WM_WINDOWPOSCHANGED
10. 000A0AD8 [0 efee9c] WM_WINDOWPOSCHANGING (WINDOWPOS.flags is 4014)
11. 000A0AD8 [1 0] WM_SHOWWINDOW
12. 000A0AD8 [0 efee9c] WM_WINDOWPOSCHANGING
13. 00130A2E [0 efee9c] WM_WINDOWPOSCHANGING
14. 00130A2E [0 a0ad8] WM_NCACTIVATE
15. 00130A2E [0 a0ad8] WM_ACTIVATE
    ...

In a working build, line 10 and on do not occur, and other painting and mouse related messages are sent as normal.

I'm not sure what specifically triggers the difference, but it has something to do with being the default browser. Running with '-setDefaultBrowser' is enough to trigger the issue on a build that doesn't have this issue, but resetting the default browser afterwards does not make the issue go away again. Moving the build to a different directory does make the issue disappear again.

firefox is not my default browser and i have this issue as well

Comment 57

[Marco Bonardo [:mak]]

(In reply to marco smith from comment #55)

firefox is not the default browser on my computer and i have this issue

There can be a relation regardless, setting Firefox as the default browser makes it much easier to reproduce, once this bug is fixed you can tell us if the problem still exists in your case and can be evaluated apart. Thanks.

Comment 58

[Marco Bonardo [:mak]]

Neil, do you plan to take this, or can you suggest someone with knowledge of the code handling these Windows messages, that may look into it? Eventually we could also contact Microsoft to understand the scope for those additional messages (I'm happy to do that, if you think it may be a bug on their side, or their insight may be useful). wdyt?
(note: I'm just trying to ensure this has a path towards resolution, and doesn't get lost)

Comment 59

[Neil Deakin]

There are a number of possible workarounds that aren't ideal:

1. Hide and destroy the popup after it is closed. That would likely cause performance issues.
2. If we are sure that it only happens when the tablet mode is changed or when sleep/wake occurs, we could hide and destroy popups at that time.
3. Hide and destroy the popup when the extra show message occurs. My somewhat limited testing suggests that we can't prevent showing the popup, so while this limits the times when we need to remove the popup, it might have noticeable flickering.

I don't have enough knowledge to know why the message might be being sent. Presumably it is some change made to this specific version of Windows and it would be good to find out and understand what that change was and what it was for.

Comment 63

[Julie]

I never mentioned the make and model of my Laptop with this problem. I have only had the problem in Laptop mode, although the HP Spectre x360 Convertible 13 has a tablet mode, I rarely use that mode.

Comment 65

[Neil Deakin]

We should fix this sooner rather than later I think.

Comment 66

[Dão Gottwald [:dao]]

jimm, can you help us find an owner for this?

Comment 67

[Itiel]

fwiw I can reproduce this issue on my desktop, when switching to tablet mode. So this is probably not limited only to laptops/tablets.
I'm using Windows 10 x64 1809.

Comment 68

[Sylvestre Ledru [:Sylvestre]]

The number of dupe is worrying. We should probably track it.

Comment 69

[Neil Deakin]

Attachment: This is a hacky patch that does (3) from comment 59.

This workaround handles the switch out of tablet mode at least and doesn't have any noticeable flicking or issues that I can see. It could be used if a real fix can't be found.

Comment 70

[Liz Henry (:lizzard) (relman/hg->git project)]

This looks like a severe enough issue to be a blocker for 66. Since Windows users are now being updated automatically to version 1809 we're getting a lot of duplicate reports of this problem. Following up with jimm.

Comment 71

[Jim Mathies [:jimm]]

unassigned -> p2. I'm looking for a good owner.

Comment 72

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

This seems to have been fixed on Windows 10 Insider Preview somewhere between 18323 and 18343, on both my VM and laptop it reproduces on '23 but not after upgrade to '43 (with a fresh install and forcing with -SetDefaultBrowser each time). The 18342 release notes did mention some tablet mode fixes, though they don't seem to directly relate to this. I'll mention it on the Microsoft discussion list to see if gets in front of someone who knows about the fix.

It's going to be a while before 1903 actually gets out to users, so it's still worthwhile trying to work around it for 1809.

It looks like this started with the introduction of level="parent" in bug 1264983, removing that line seems to fix it, so that's a possible lead. I'll keep looking into this.

Comment 73

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

I tracked down the seeming dependency on -SetDefaultBrowser (or helper.exe in general): What's really important here just is our Software\Mozilla\Firefox\TaskBarIDs registry key. If there's a value matching our path, then we call SetCurrentProcessExplicitAppUserModelID from the Windows nsWindow constructor via RegisterAppModelID. With that line removed, the issue does not reproduce, and with SetCurrentProcessExplicitAppUserModelID I can reproduce the behavior in a small test program. This makes a lot more sense than it being related to browser detection, it's just a window manager issue.

Still looking into a workaround.

Comment 74

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

I like Neil's patch, I changed it to block SWP_SHOWWINDOW while handling WM_WINDOWPOSCHANGING, as is done for the invisible window. That way we wouldn't switch to shown even temporarily, and it wouldn't require an extra message. In my testing this eliminates the little bit of flicker we get with show then hide (the drop shadow at the bottom border is very briefly visible).

Try run ongoing at: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e5041bacf10135c95f269cdda8334078f9607c3f

Comment 75

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: Bug 1498973: Don't show a popup that should be hidden. r?jmathies

Comment 77

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Comment on attachment 9046385 [details] [diff] [review]
This is a hacky patch that does (3) from comment 59.

Fix queued up on Lando, should be available once autoland reopens.

While I can easily reproduce the issue with the search dropdown when switching in and out of tablet mode, I have not yet been able to reliably reproduce when waking from sleep mode, or with other popups. I've seen both cases occasionally, and I assume that this patch should fix those as well, but I can't confirm it. For the same reason I can't confirm that those cases are fixed by themselves in Windows 10 1903 build 18434. If anyone has steps to reproduce those I'd like to give them a try.

But I think this patch should handle all causes of these symptoms.

Comment 78

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/067c36284e77
Don't show a popup that should be hidden. r=jmathies

Comment 79

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/067c36284e77

Comment 80

[Liz Henry (:lizzard) (relman/hg->git project)]

Can you request beta uplift? Thanks!

Comment 81

[Liz Henry (:lizzard) (relman/hg->git project)]

After some discussion with Adam we're going to let this bake over the weekend in Nightly. Some possible concerns to look out for in regressions / new bug reports could be external apps (such as accessibility apps) which unhide invisible windows. We could still consider uplift for this for the RC build or a 2nd RC. It was broken in 65 so probably shouldn't block 66; if we don't get this fix into 66 release then we could note it as a known issue.

This is also going to be fixed in the 1903 Windows update.

Comment 82

[Dão Gottwald [:dao]]

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #81)

It was broken in 65 so probably shouldn't block 66;

I'm not sure this is sound. The reason for making this block 66 was that "Windows users are now being updated automatically to version 1809". Whether it was broken in 65 doesn't really matter if the concern is that the bulk of users are yet to update to 1809. Do we have numbers on the update rate?

This is also going to be fixed in the 1903 Windows update.

... which may take several months to reach most end users if the 1809 release is any indication.

Comment 83

[Liz Henry (:lizzard) (relman/hg->git project)]

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

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #81)

It was broken in 65 so probably shouldn't block 66;

I'm not sure this is sound. The reason for making this block 66 was that
"Windows users are now being updated automatically to version 1809". Whether
it was broken in 65 doesn't really matter if the concern is that the bulk of
users are yet to update to 1809. Do we have numbers on the update rate?

Microsoft (re)turned on auto-updates for 1809 in mid-January. Because that's around when we started getting reports of the problem, I thought it might be from users updating more quickly. But, now that I look deeper, it turns out you are completely right, the rollout is still very slow. We still are seeing the bulk of Firefox/Windows users on the 1803 update (https://sql.telemetry.mozilla.org/dashboard/windows-10-user-strata) on beta and release. Nightly users are much more likely to be on 1809, but more than half are still on 1803.

Adam, this makes me lean more heavily towards trying uplift (even for Monday's build.) We could accept the risk of regressions and aim to discover them and fix them in a dot release later in the 66 cycle.

Comment 84

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Comment on attachment 9047876 [details]
Bug 1498973: Don't show a popup that should be hidden. r?jmathies

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: Windows 10 version 1809
• User impact if declined: Hidden popups may be redisplayed in an unusable state when switching tablet mode on then off, or sometimes when waking from sleep mode. This is mostly harmless, but the popups get in the way and the easiest workaround is to restart the browser. A Windows fix is available but is not likely to be out for some months.
• Is this code covered by automated tests?: Unknown
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): Risky: All Windows commands to show Firefox popups are filtered through this mechanism. If there are any third-party apps selectively unhiding our inactive popups, or if there is some mechanism that shows popups before they are officially "opened", they won't be shown. This has had little time in the wider population (only a few days on Nightly) to catch these or unexpected issues.

Not risky: The change is limited to Windows 10 version 1809 and up, so many backwards compatibility issues are avoided.

• String changes made/needed:

Comment 85

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9047876 [details]
Bug 1498973: Don't show a popup that should be hidden. r?jmathies

Fix for release-blocking issue which we expect would affect more users in 66 than in 65. OK for uplift.

Comment 86

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-release/rev/481d211be2ff

Comment 87

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backed out for bustage - IsWin10Sep2018UpdateOrLater not declared:

https://hg.mozilla.org/releases/mozilla-release/rev/e5dc798ba83b99c6c8a94795a3dce55450853566

Push with bustage: https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&resultStatus=usercancel%2Cretry%2Ctestfailed%2Cbusted%2Cexception%2Crunnable&group_state=expanded&revision=481d211be2ffad0d806292ebce8d3e242a8ca34d
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=233181922&repo=mozilla-release

19:39:15 INFO - mozmake.EXE[5]: Entering directory 'z:/build/build/src/obj-firefox/widget/windows'
19:39:15 INFO - z:/build/build/src/clang/bin/clang.exe --driver-mode=cl -m32 -FoUnified_cpp_widget_windows2.i_o -c -Iz:/build/build/src/obj-firefox/dist/stl_wrappers -DNDEBUG=1 -DTRIMMED=1 -DWIN32_LEAN_AND_MEAN -D_WIN32 -DWIN32 -D_CRT_RAND_S -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS -DOS_WIN=1 -D_UNICODE -DCHROMIUM_BUILD -DU_STATIC_IMPLEMENTATION -DUNICODE -D_WINDOWS -D_SECURE_ATL -DCOMPILER_MSVC -DMOZ_UNICODE -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -Iz:/build/build/src/widget/windows -Iz:/build/build/src/obj-firefox/widget/windows -Iz:/build/build/src/obj-firefox/ipc/ipdl/_ipdlheaders -Iz:/build/build/src/ipc/chromium/src -Iz:/build/build/src/ipc/glue -Iz:/build/build/src/layout/forms -Iz:/build/build/src/layout/generic -Iz:/build/build/src/layout/xul -Iz:/build/build/src/toolkit/xre -Iz:/build/build/src/widget -Iz:/build/build/src/widget/headless -Iz:/build/build/src/xpcom/base -Iz:/build/build/src/obj-firefox/dist/include -Iz:/build/build/src/obj-firefox/dist/include/nspr -Iz:/build/build/src/obj-firefox/dist/include/nss -MD -FI z:/build/build/src/obj-firefox/mozilla-config.h -DMOZILLA_CLIENT -Qunused-arguments -guard:cf -Qunused-arguments -fcrash-diagnostics-dir=z:/build/public/build -TP -nologo -w15038 -wd5026 -wd5027 -Zc:sizedDealloc- -wd4091 -wd4577 -D_HAS_EXCEPTIONS=0 -guard:cf -W3 -Gy -Zc:inline -arch:SSE2 -Gw -wd4251 -wd4244 -wd4267 -wd4800 -wd4595 -wd4065 -Wno-inline-new-delete -Wno-invalid-offsetof -Wno-microsoft-enum-value -Wno-microsoft-include -Wno-unknown-pragmas -Wno-ignored-pragmas -Wno-deprecated-declarations -Wno-invalid-noreturn -Wno-inconsistent-missing-override -Wno-implicit-exception-spec-mismatch -Wno-unused-local-typedef -Wno-ignored-attributes -Wno-used-but-marked-unused -we4553 -D_SILENCE_TR1_NAMESPACE_DEPRECATION_WARNING -GR- -Zi -Xclang -load -Xclang z:/build/build/src/obj-firefox/build/clang-plugin/clang-plugin.dll -Xclang -add-plugin -Xclang moz-check -O2 -Oy- -Iz:/build/build/src/obj-firefox/dist/include/cairo -fprofile-instr-generate -Xclang -finstrument-functions-after-inlining -Xclang -MP -Xclang -dependency-file -Xclang .deps/Unified_cpp_widget_windows2.i_o.pp -Xclang -MT -Xclang Unified_cpp_widget_windows2.i_o -Fdgenerated.pdb -FS z:/build/build/src/obj-firefox/widget/windows/Unified_cpp_widget_windows2.cpp
19:39:15 INFO - In file included from z:/build/build/src/obj-firefox/widget/windows/Unified_cpp_widget_windows2.cpp:110:
19:39:15 INFO - z:/build/build/src/widget/windows/nsWindow.cpp(4932,7): warning: expression result unused; should this cast be to 'void'? [-Wunused-value]
19:39:15 INFO - (void*)GetAccessible();
19:39:15 INFO - ^ ~
19:39:15 INFO - z:/build/build/src/widget/windows/nsWindow.cpp(6548,35): error: use of undeclared identifier 'IsWin10Sep2018UpdateOrLater'; did you mean 'IsWin10April2018UpdateOrLater'?
19:39:15 INFO - static bool sDWMUnhidesPopups = IsWin10Sep2018UpdateOrLater();
19:39:15 INFO - ^~~~~~~~~~~~~~~~~~~~~~~~~~~
19:39:15 INFO - IsWin10April2018UpdateOrLater
19:39:15 INFO - z:/build/build/src/obj-firefox/dist/include\mozilla/WindowsVersion.h(153,24): note: 'IsWin10April2018UpdateOrLater' declared here
19:39:15 INFO - MOZ_ALWAYS_INLINE bool IsWin10April2018UpdateOrLater() {
19:39:15 INFO - ^
19:39:15 INFO - 1 warning and 1 error generated.
19:39:15 INFO - z:/build/build/src/config/rules.mk:1106: recipe for target 'Unified_cpp_widget_windows2.i_o' failed
19:39:15 INFO - mozmake.EXE[5]: *** [Unified_cpp_widget_windows2.i_o] Error 1

Comment 88

[Liz Henry (:lizzard) (relman/hg->git project)]

This will also need the patch in bug 1528045.

Comment 89

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-release/rev/6776dac63175

Comment 90

[Liz Henry (:lizzard) (relman/hg->git project)]

We will have to back this out and do an RC3.
Adam will investigate bug 1534935 and we can aim to re-land this fix in a dot release during the 66 cycle.

Comment 91

[Liz Henry (:lizzard) (relman/hg->git project)]

Pascal, if you're ok with it, I'd like to leave this in 67 for beta 2 so we can see if there are any other regressions (because it's a bad bug that we'd like to fix during 66 release). So if we could leave these patches in 67 for today, you could back them out if you like for 67.0b3. What do you think?

Comment 92

[Pascal Chevrel:pascalc]

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #91)

Pascal, if you're ok with it, I'd like to leave this in 67 for beta 2 so we can see if there are any other regressions (because it's a bad bug that we'd like to fix during 66 release). So if we could leave these patches in 67 for today, you could back them out if you like for 67.0b3. What do you think?

It's OK for me, if we don't get a fix tomorrow, we will back out from mozilla-central before the final merge and beta 3.

Comment 93

[Dorel Luca [:dluca]]

Backed out changeset 6776dac63175 (bug 1498973) for regression from bug 1534935 at Lizzard's request

Backout:
https://hg.mozilla.org/releases/mozilla-release/rev/164a57c0cdf0088e786e6b966e34fdd3799671d1

Comment 95

[Julien Cristau [:jcristau]]

Comment on attachment 9047876 [details]
Bug 1498973: Don't show a popup that should be hidden. r?jmathies

Clearing release approval since this was backed out.

Comment 96

[Liz Henry (:lizzard) (relman/hg->git project)]

We will likely be preparing for a dot release next week so we could try landing this again on m-r. (Not this week, though, please .) Adam, what do you think?

Comment 97

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

I'm fine with giving it another shot. If nothing pops up on beta over the next week or so then I'll put in for the uplift. Fortunately the bug 1534935 regression was very straightforward.

Comment 98

[Pascal Chevrel:pascalc]

(In reply to Adam Gashlin [:agashlin] from comment #97)

I'm fine with giving it another shot. If nothing pops up on beta over the next week or so then I'll put in for the uplift. Fortunately the bug 1534935 regression was very straightforward.

Adam, could you prepare an uplift for release if you think is still makes sense to include it in 66.0.2? Thanks!

Comment 99

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Sure! Should I just post a raw patch here that can land by itself, rolling up the one-line fix for bug 1534935?

Also I don't know how landing works on release, would I be able to push this myself or do I need to get a sheriff to do it?

Comment 100

[Pascal Chevrel:pascalc]

(In reply to Adam Gashlin [:agashlin] from comment #99)

Sure! Should I just post a raw patch here that can land by itself, rolling up the one-line fix for bug 1534935?

Also I don't know how landing works on release, would I be able to push this myself or do I need to get a sheriff to do it?

Landing is done by Sheriffs. Attach a patch that applies cleanly to the mozilla-release repo and ask for an uplift (select the 'approval-mozilla-release:?' flag in the attachment page and fill in the uplift form that appears in Bugzilla which gives release managers information about the uplift that help them in their decision process, maybe this article may be more explicit as it has screenshots:
https://release.mozilla.org/tooling/bugzilla/2018/10/03/uplift-form.html

Comment 101

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: Bug 1498973 uplift for 66.0.2 release (incl. 1534935 fix). r=jmathies

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: Windows 10 version 1809
• User impact if declined: Hidden popups may be redisplayed in an unusable state when switching tablet mode on then off, or sometimes when waking from sleep mode. This is mostly harmless, but the popups get in the way and the easiest workaround is to restart the browser.
• Is this code covered by automated tests?: Unknown
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): There are many mechanisms that show popups, and automated test coverage is not present for all of them. Some mechanisms may not be used in all builds so even manual testing might not catch them. This could result in parts of the interface being invisible.

That said, this has been on Nightly for a few weeks, and Beta for about a week, with no reported issues since bug 1534935 was fixed (and that fix was straightforward).

Alternatives: A Windows fix is available but is not likely to be distributed for some months.

• String changes made/needed:
• Do you want to request approval of these patches as well?: on

Comment 102

[Pascal Chevrel:pascalc]

The uplift request is coming too late for 66.0.2 but if we have a 66.0.3 release, we can include the patch in this release. I'll let Liz decide when she comes back from PTO next week.

Comment 103

[Cristian Craciun]

Build ID: 20190325125126
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Verified as fixed on the latest Nightly and on the latest Beta build.

Comment 104

[Marco Bonardo [:mak]]

Adam, thank you for fixing this bug, it's critical for us that the Address Bar works properly, we greatly appreciate your help.

Comment 106

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9053671 [details] [diff] [review]
Bug 1498973 uplift for 66.0.2 release (incl. 1534935 fix). r=jmathies

I'd like to include this for a 66.0.3 release.

Comment 108

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-release/rev/4400ca694ade

Comment 109

[Liz Henry (:lizzard) (relman/hg->git project)]

Adding to release notes for 66.0.3 as "FIXED: Performance issues with some HTML5 games "

Comment 110

[Liz Henry (:lizzard) (relman/hg->git project)]

Oops. Wrong bug. This is noted as "FIXED: Address bar on tablets running Windows 10 now behave correctly."

Comment 111

[Cristian Craciun]

Build ID: 20190409155332
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Verified as fixed on the latest Release build (66.0.3)

Comment 112

[xracoonx]

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #110)

Oops. Wrong bug. This is noted as "FIXED: Address bar on tablets running Windows 10 now behave correctly."

Does that mean, contrary to the title, that all overlays have been fixed, e.g. menu, site information, etc.?

Comment 113

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

(In reply to xracoonx from comment #112)

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #110)

Oops. Wrong bug. This is noted as "FIXED: Address bar on tablets running Windows 10 now behave correctly."

Does that mean, contrary to the title, that all overlays have been fixed, e.g. menu, site information, etc.?

I wasn't able to reproduce the other overlay issues consistently to verify that they were fixed as well, but I strongly suspect they were. If anyone has workable steps to reproduce those, I'll be glad to check.

Comment 114

[Ren Wargner]

Hey guys,

2 days ago my Firefox deleted the theme and the adblocker by itself, and now when i'm trying to readd, it says i have ethernet connection errors, however, i don't.

Have any of you experienced something like this?

Help will be much appreciated.

Comment 115

[[:philipp]]

hello ren, please don't hijack a arbitrary bug report for a different problem - refer to the banner that's currently displayed on top of bugzilla.mozilla.org about the problem with addons you're currently experiencing.

Comment 116

[Firefox Bug Husbandry Bot]

Please specify a root cause for this bug. See :tmaity for more information.

Comment 117

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

The root cause was a Windows 10 bug introduced in 1809 ("October 2018 Update") and fixed in 1903 ("May 2019 Update"). The fix here is a workaround.