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

VERIFIED FIXED in Firefox 66

Status

()

defect
P1
major
VERIFIED FIXED
6 months ago
6 days ago

People

(Reporter: joviedo, Assigned: agashlin)

Tracking

(Blocks 1 bug, {regression, regressionwindow-wanted})

62 Branch
mozilla67
Points:
---
Dependency tree / graph
Bug Flags:
in-qa-testsuite +

Firefox Tracking Flags

(relnote-firefox 66+, firefox-esr60 wontfix, firefox65 wontfix, firefox66blocking verified, firefox67+ verified, firefox68 verified)

Details

(Whiteboard: [see comment 42 and comment 53])

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

6 months ago
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
Component: Untriaged → Address Bar
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
Flags: needinfo?(dao+bmo)
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.
Flags: needinfo?(dao+bmo)
(Reporter)

Comment 3

6 months ago
I have uploaded a video with the error process

https://www.youtube.com/watch?v=NLaC_zANj7c
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 :/
Blocks: tabletmode
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
See Also: → 1470643
Summary: {Surface} the address bar is always visible and not hidden → {Surface} Switching to tablet mode opens the address bar panel, and it doesn't close until typing
Duplicate of this bug: 1497305

Comment 6

6 months ago
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

5 months ago
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

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

Comment 9

5 months ago
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

Updated

5 months ago
Duplicate of this bug: 1508068

Comment 11

5 months ago
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?
Flags: needinfo?(mak77)
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.
Flags: needinfo?(mak77)

Comment 13

5 months ago
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?
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

5 months ago
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

5 months ago
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?
Flags: needinfo?(joviedo)
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

4 months ago
(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.
(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

4 months ago
(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.
Meaning... the default home page? about:blank?

Comment 22

4 months ago
Meaning the problem occurs with any of the pages you mentioned loaded but also without any of those loaded.
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.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Priority: P5 → P2
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.
Flags: needinfo?(joviedo)
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

4 months ago
(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
Duplicate of this bug: 1517068
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.
Flags: needinfo?(enndeakin)

Comment 29

4 months ago
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.
Component: Address Bar → Widget: Win32
Flags: needinfo?(enndeakin)
Product: Firefox → Core
I wonder if we could release a Nightly with some additional logging for this.

Comment 31

4 months ago
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

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

Comment 33

4 months ago
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.
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.
Assignee: mak77 → nobody
Status: ASSIGNED → NEW

Comment 35

4 months ago

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 37

3 months ago

(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.

Updated

3 months ago
Duplicate of this bug: 1521297
Duplicate of this bug: 1519297

Comment 40

3 months ago

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

Comment 41

3 months ago

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

(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
Flags: needinfo?(enndeakin)
Summary: {Surface} Switching to tablet mode opens the address bar panel, and it doesn't close until typing → {Surface} Switching to tablet mode shows a sticky address bar panel, when Firefox is the default browser

Updated

3 months ago
Duplicate of this bug: 1523709
Comment hidden (me-too)
Comment hidden (me-too)

Updated

3 months ago
Duplicate of this bug: 1524831

Updated

3 months ago
Duplicate of this bug: 1523927

Updated

2 months ago
Duplicate of this bug: 1526655

Updated

2 months ago
Duplicate of this bug: 1526483

Updated

2 months ago
Duplicate of this bug: 1526325

Updated

2 months ago
Duplicate of this bug: 1526629

Comment 52

2 months ago

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

2 months ago
important

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.

Flags: needinfo?(enndeakin)

Comment 54

2 months ago

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

Comment 55

2 months ago

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

Comment hidden (obsolete)

(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.

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)

Flags: needinfo?(enndeakin)
Whiteboard: [see comment 42 and comment 53]

Comment 59

2 months ago

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.

Flags: needinfo?(enndeakin)

Updated

2 months ago
Duplicate of this bug: 1521375

Updated

2 months ago
Duplicate of this bug: 1529786

Updated

2 months ago
Duplicate of this bug: 1530147

Comment 63

2 months ago

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.

Updated

2 months ago
Duplicate of this bug: 1530184

Comment 65

2 months ago

We should fix this sooner rather than later I think.

Priority: P2 → P1

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

Flags: needinfo?(jmathies)

Comment 67

2 months ago

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.

Summary: {Surface} Switching to tablet mode shows a sticky address bar panel, when Firefox is the default browser → Waking up from sleep / switching to tablet mode shows a sticky address bar panel, when Firefox is the default browser
Severity: normal → major

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

Comment 69

2 months ago

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.

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.

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

Flags: needinfo?(jmathies)
Priority: P1 → P2
(Assignee)

Comment 72

2 months ago

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.

(Assignee)

Updated

2 months ago
Assignee: nobody → agashlin
Priority: P2 → P1

Updated

2 months ago
Blocks: 1264983
(Assignee)

Comment 73

2 months ago

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.

(Assignee)

Comment 74

2 months ago

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

Updated

2 months ago
Duplicate of this bug: 1533046
(Assignee)

Comment 77

2 months ago
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.
Attachment #9046385 - Attachment is obsolete: true

Comment 78

2 months ago
Pushed by agashlin@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/067c36284e77
Don't show a popup that should be hidden. r=jmathies

Comment 79

2 months ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

Can you request beta uplift? Thanks!

Flags: needinfo?(agashlin)

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.

(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.

Flags: needinfo?(lhenry)

(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.

Flags: needinfo?(lhenry)

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:
Flags: needinfo?(agashlin)
Attachment #9047876 - Flags: approval-mozilla-beta?

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.

Attachment #9047876 - Flags: approval-mozilla-release+
Attachment #9047876 - Flags: approval-mozilla-beta?
Attachment #9047876 - Flags: approval-mozilla-beta-

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

Flags: needinfo?(agashlin)

This will also need the patch in bug 1528045.

(Assignee)

Updated

a month ago
Flags: needinfo?(agashlin)

Updated

a month ago
Depends on: 1534935

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.

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?

Flags: needinfo?(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.

Flags: needinfo?(pascalc)

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

Updated

a month ago
Duplicate of this bug: 1535543

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.

Attachment #9047876 - Flags: approval-mozilla-release+

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?

Flags: needinfo?(agashlin)

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.

Flags: needinfo?(agashlin)
Flags: qe-verify+

(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!

Flags: needinfo?(agashlin)

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?

Flags: needinfo?(agashlin) → needinfo?(pascalc)
QA Whiteboard: [qa-triaged]

(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

Flags: needinfo?(pascalc)

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
Attachment #9053671 - Flags: approval-mozilla-release?

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.

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.

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

Updated

26 days ago
Duplicate of this bug: 1540313
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.
Attachment #9053671 - Flags: approval-mozilla-release? → approval-mozilla-release+
Duplicate of this bug: 1512853

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

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

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)

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+

Comment 112

10 days ago

(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.?

Flags: in-qa-testsuite?(andrei.vaida)

(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.

Flags: in-qa-testsuite?(andrei.vaida) → in-qa-testsuite+
You need to log in before you can comment on or make changes to this bug.