1268476 - [Elevated Update] Software update windows are not visible

Status: RESOLVED DUPLICATE of bug 1521632

(Toolkit :: Application Update, defect)

Description

[Adrian Florinescu [:aflorinescu]]

[Description]
This issue refers to the update windows which needs to be modal. Currently the "Update software" windows are most of the time behind the main browser window.

[Affected OS]:
-OSX all

[Affected versions]:
-Nightly Oak build 


[Steps]:
1. Install FF on admin user.
2. Switch to standard/guest user.
3. Check for updates.
4. Restart to update. 
5. Firefox Restarts and the Software Update/ Update ready to Install is pop-ed up. 
6. Press Restart Nightly. (elevate update is triggered here)
7. In the elevated user dialog press Cancel


[Actual Result]:
for STR 5-6:
Nightly is restarted and shows the Update Ready to install window with 3 available options:
-Restart later
-No thanks
-Restart Nightly

for STR 7:
Nightly is restarted and Update failed window is usually behind FF.

[Expected Result]:
STR: 5-7 
All update windows are expected to be in front of the browser and i would push even more expecting them to be modal. 

[Notes]:
I believe that in most of the normal update cases the update window is started after the browser, which places the update window in front of the browser. However, in case of the elevated updater, the update window ends up in majority of the cases behind the browser.

Comment 1

[Stephen A Pohl [:spohl]]

Based on the fact that the update failure dialog (existing dialog) exhibits the same behavior, I must assume that this is an existing issue. Robert, do you have any input here? I'm not sure how difficult it would be to ensure that the update dialog is in the foreground after the Firefox window is displayed, but it doesn't seem straightforward.

Comment 2

[Robert Strong (they/them - no direct email)]

It is an old bug and shouldn't block your work. Specifically, bug 311614.

Comment 3

[Adrian Florinescu [:aflorinescu]]

I agree that the dupe and our issue are similar, but I'd like to underline that the update window we're talking about is a new one (if i'm not mistaking) and it is opened when you restart to elevate.  In that respect, I think I went a bit too far by assuming it has to be modal: the order in which the browser and the update window are opened are "wrong" and if we would open the browser first and then the updater one (gathering that it is an easy change) it would fix this problem. 

Our concern is that the user restarts the browser specifically to update/elevate hence we think it's not intuitive to have that update window hidden.

Comment 4

[Robert Strong (they/them - no direct email)]

It is the same window with different content.
It will likely need a hack to fix it or at the very least it will need to listen to an additional startup event which is why the bug this was duped to hasn't been fixed yet.

I'll discuss the feasibility of fixing the bug this was duped to with Stephen today.

Comment 5

[Adrian Florinescu [:aflorinescu]]

Build ID 0160602030220 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:49.0) Gecko/20100101 Firefox/49.0 

Although now intermittent, the elevate window appears sometimes (50%) behind the browser.

Reopening this bug as per https://bugzilla.mozilla.org/show_bug.cgi?id=311614#c75 as it contains STR. 

Note: When we used the files and steps that Stephen gave us in https://bugzilla.mozilla.org/show_bug.cgi?id=311614#c64 for the above Nightly build, the position of the window was always in front of the browser.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I run our firefox-ui fallback update tests a couple of times and was not able to see this problem. The old software update dialog always opens in-front of the brower.

Adrian, I assume you have a checkout of mozilla-central? If yes can you please run the following command and check if you see it maybe on your machine?

> $ mach firefox-ui-update --update-fallback-only --binary %path_to_pre_build%

The pre build is actually the build you are using when testing it manually. Thanks

Comment 7

[Robert Strong (they/them - no direct email)]

Henrik, can you reproduce using the steps provided by Adrian? Do the firefox-ui-update tests use the same steps as those provided by Adrian? If you can reproduce or if the firefox-ui-update tests don't use the same steps then I think it is pointless to have Adrian run those tests.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Hm, so which steps would that be exactly? I have a hard time to find that out. Not sure what is meant with "best reproducible in the case of first elevate cancel". Thanks.

Comment 9

[Robert Strong (they/them - no direct email)]

We ask for the steps to reproduce a bug to be in comment #0, they are in comment #0 of this bug, and I doubt those are the steps the firefox-ui-update tests use. As for the other ways to reproduce it I'll leave that to Adrian to provide the exact steps.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I missed comment 0 because it was hidden by default for me initially. So reading through the steps now it might indeed not make sense. The tests require admin permissions to run, means we do not test the elevated update part as layed out there.

Comment 11

[Robert Strong (they/them - no direct email)]

Henrik, besides the Firefox about dialog the in tree mochitest-chrome tests already test everything the firefox-ui-update tests test for as well as quite a bit more. So it is extremely doubtful that it will be helpful to ask QA or devs to run the firefox-ui-update tests in the future. We know they are there and if we decide they will be helpful we'll just run them.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Well, the elevated update changes broke our update tests on OS X as it is tracked on bug 1276220. So this part hasn't been tested upfront. Maybe we would need a new bug to discuss how we could get those tests run with inbound builds or an own build. But as you say it's different from this bug, so I will stop now. :)

Comment 13

[Robert Strong (they/them - no direct email)]

(In reply to Henrik Skupin (:whimboo) [away 06/06 - 06/10] from comment #12)
> Well, the elevated update changes broke our update tests on OS X as it is
> tracked on bug 1276220. So this part hasn't been tested upfront. Maybe we
> would need a new bug to discuss how we could get those tests run with
> inbound builds or an own build. But as you say it's different from this bug,
> so I will stop now. :)
Those tests have typically been fragile and also tested things that were already tested which doesn't provide value over the existing tests while breaking when those parts of app update change. Getting those tests to run as part of the build system would definitely catch regressions in those tests and releng should be able to help you with that.

Comment 14

[Robert Strong (they/them - no direct email)]

All but the in app request for elevation UI has been replaced and that will also be replaced with a doorhanger by bug 1521632 so duping to bug 1521632 for any remaining issues with the UI being in front.