1349286 - Consider checking/downloading upgrades when a captive portal has been detected

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, enhancement, P5)

Description

[Jonathan Kingston [:jkt] he/him]

On a flight I had a limitation of 150mb that I had paid for through the payment required captive portal.

Unknowingly I burned through around 60mb on a nightly update.

Could we consider some heuristics or user required manual update when the user has seen a captive portal?

Comment 1

[Honza Bambas (:mayhemer)]

If you are on Windows (8+ I think) you can mark a connection as paid.  It will limit number of things in windows.  We should then respect that setting too.  

Personally I don't think that detection of a portal is a good marking of a connection being potentially FUP'ed.

Comment 2

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

(In reply to Honza Bambas (:mayhemer) from comment #1)
> If you are on Windows (8+ I think) you can mark a connection as paid.  It
> will limit number of things in windows.  We should then respect that setting
> too.  
> 
> Personally I don't think that detection of a portal is a good marking of a
> connection being potentially FUP'ed.
Honza, when you say, "We should then respect that setting too" do you mean that we already respect that setting?

Comment 3

[Honza Bambas (:mayhemer)]

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #2)
> Honza, when you say, "We should then respect that setting too" do you mean
> that we already respect that setting?

I have no idea, sorry.

Comment 4

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

Patrick, how would you suggest the app update code determine the network state?

Comment 5

[Patrick McManus [:mcmanus]]

I think this is a bad idea - updates are important and captive portals are not the right indicator.

What hozna suggests is a os specific interface - I don't have any insight into it. sorry. And I'm sure it won't capture the OP use case.

Comment 6

[(inactive) Nihanth Subramanya [:nhnt11]]

Chiming in, having thought about it I agree that captive portal state is not the right indicator. When I was in university I was *always* behind a captive portal. Also, my current ISP here in India uses a captive portal to authenticate subscribers - I have to log in again if I disconnect my router for too long.

Interesting problem though, I wonder if it would help if we notified the user that we started downloading an update, or something. A few ideas come to me but none of them seem very actionable.

Comment 7

[Jonathan Kingston [:jkt] he/him]

Yeah I wanted to raise the issue for the discussion, I wasn't keen on preventing updates either.
It's especially crappy hearing about campus and Indian experiences.
Perhaps we could consider a manual way to snooze, pause or whatever the download. It's probably only especially a real issue on Nightly, every time I fly I get this.

Other issues are all of my tabs are active checking for requests etc, resume session on 100+ tabs is super costly too.

Comment 8

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

I probably wouldn't accept an app update implementation that isn't on all channels. Adding more notifications is a not going to happen since we are actively trying to remove as many app update notifications as possible. The people that are affected by this could always change the update setting in preferences / options so they are notified of updates and then can choose whether to download the update.

Comment 9

[Jonathan Kingston [:jkt] he/him]

Yeah I wasn't suggesting we implement something different per channel just something interesting related to nightly users.

We seem to have a new look animation for when a download is happening, perhaps we could add some form of animation on the green arrow when an upgrade is happening instead?

Comment 10

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

Bram, can I get a call from UX as to whether this is something Firefox would want to implement?

Comment 11

[Bram Pitoyo [:bram]]

We would certainly want to be smart about when to download update, but the only constraint here seems to be bandwidth.

So what we can do is something like, when you’re operating under captive portal and a new download is detected, the download doesn’t get downloaded immediately. Instead, we’ll ask users. Download Update, or Not Now?

But we also need something that won’t annoy users every time there’s a release. So maybe we’ll need to add a checkbox? This checkbox will only appear when the user is on a captive portal, and the policy that it sets is only valid for that internet connection.

It could say something like “Always remember my decision when using this internet connection”. Just to be safe, maybe it should default to *not checked*.

When you’re on a different captive portal, we’ll ask you again. But as long as you’re staying on one captive portal connection most of the time (e.g. Nihanth’s situation on comment 6), you won’t see it again.

What do you think?

Comment 12

[Patrick McManus [:mcmanus]]

again - I don't think its even common that a captive portal represents metered bandwidth, so ui would be odd and get in the way. The point of clearing the portal (most of the time!) is that stuff should just work - that includes updates.

also knowing when we're behind a captive portal that is allowing you through isn't always possible. These things are transparent, so if we haven't witnessed a login (because it happened in a different session, a different browser, whatever) we'll just think you have clean internet. fwiw.

if we're going to do something here I think it should be tied to metered bandwidth, and CP isn't a good proxy for that. (Though I'm not sure how we would determine metered - just that CP isn't a good proxy for it.)

Comment 13

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

Bram, in total agreement with comment #12. Also, I think just about any implementation such as you described would have many false positives and I highly suspect they would be in the majority. Also, the implementation as described in comment #11 is quite complex especially for something that is quite likely for the minority of use cases and it would take quite a lot of effort to implement and maintain as well.

In comment #9 it was suggested that providing an indicator that an update is happening. Do you think that is something that Firefox would want? I'm somewhat concerned about there being an indication that an update is happening for everyone since there has been so much effort to not show any indication which is why I am asking whether UX thinks an indication is something Firefox would want.

Comment 14

[Bram Pitoyo [:bram]]

(In reply to Patrick McManus [:mcmanus] from comment #12)
> if we're going to do something here I think it should be tied to metered
> bandwidth, and CP isn't a good proxy for that.

Agreed. My design was a workaround to Firefox not being able to detect when it’s operating on a connection with metered bandwidth. Ideally, we’d be able to detect connection type and automatically shift to a download policy that makes sense without user input (unless you’ve manually set it to a different value).


(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #13)
> In comment #9 it was suggested that providing an indicator that an update is
> happening. Do you think that is something that Firefox would want?

No. I think having a “Downloading update” indicator would be distracting. As you wrote, we’d like the update experience to be as silent as possible.

Here’s another heuristics to try: detect update type or file size. When it’s small or just a hotfix (≤10mb – we’ll have to think about the right size), then download it immediately. When it’s large (≥50mb), then defer the download for a short time – enough for you to finish the flight or get home, when you’re no longer on a metered connection. However, if your situation doesn’t change after x hours, then download the update.

Comment 15

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

If this is ever implemented I don't think this should be implemented in just app update and should be implemented at the networking level. For starters we've just implemented BITS on Windows for downloading updates so the majority of our clients won't even be using Firefox to download updates.