Re: Windows XP and Vista Long Term Support Plan

[Gervase Markham]

On 22/10/16 10:16, keithgallis...@gmail.com wrote:
> My concern is that by killing digital certificate updates and TLS
> updates, still in use machines whose main purpose is Internet access
> are essentially bricked.

This is a feature, not a bug. If those machines shouldn't be on the
Internet, and things happen which keep them off the Internet, then hooray.

Gerv
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Gervase Markham]

On 22/10/16 18:12, Ehsan Akhgari wrote:
> Have we considered doing something here to help the user when we block
> this API?  For example, we could check to see whether the site has a TLS
> version 

If there were a reliable way to do this, HTTPS Everywhere would be a
whole lot easier to write and maintain :-) AIUI, it's not as simple as
adding an extra s to the protocol, doing a fetch and seeing if the
response is 2xx.

Gerv

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Kan-Ru Chen]

On Sat, Oct 22, 2016, at 09:38 PM, Richard Barnes wrote:
> On Fri, Oct 21, 2016 at 5:56 PM, Ehsan Akhgari 
> wrote:
> > Since the proposal in the bug is adding [SecureContext] to
> > Navigator.geolocation, have we also collected telemetry around which
> > properties and methods are accessed?  Since another kind of breakage we
> > may encounter is code like |navigator.geolocation.getCurrentPosition()|
> > throwing an exception and breaking other parts of site scripts...
> >
> 
> I'm not picky about how exactly we turn this off, as long as the
> functionality goes away.  Chrome and Safari both immediately call the
> error handler with the same error as if the user had denied permission.  We
> could do that too, it would just be a little more code.

I would be OK with this change if it is implemented in a way compatible
with Chrome and Safari. Looks like they both call the error handler and
show an error in the console when the request is denied. And it should
be behind a pref so we can monitor it's usage during the release cycle.

Kanru
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows XP and Vista Long Term Support Plan

[keithgallistel]

On Saturday, October 22, 2016 at 4:27:32 AM UTC-5, Martin Thomson wrote:
> Yep, I just designated a relatives machine to recycling on that basis.
> I could have updated the OS, but they had other better options, so
> we're reclaiming the space.  I know that neither option is that
> pleasant, but it's not doing anyone a service to have these machines
> on the internet.


I'm free tech support for my family as well. My worry is those who don't have 
access to tech support of some form to help them with the next step. I know 
some tech stores specialize in helping customers with old machines, but that 
assumes that the type of person who needs that help knows where to find it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows XP and Vista Long Term Support Plan

[keithgallistel]

On Monday, October 24, 2016 at 3:12:31 AM UTC-5, Gervase Markham wrote:
> On 22/10/16 10:16, keithgallis...@gmail.com wrote:
> > My concern is that by killing digital certificate updates and TLS
> > updates, still in use machines whose main purpose is Internet access
> > are essentially bricked.
> 
> This is a feature, not a bug. If those machines shouldn't be on the
> Internet, and things happen which keep them off the Internet, then hooray.
> 
> Gerv

Like I've said in previous messages on this thread, I agree that XP and Vista 
should be placed on ESR 52, but I'm worried about those people who don't have 
access to tech support at home (friends, family, a tech store, etc.) to help 
them with the next steps of replacing their old machine. It would be good if 
Mozilla had some kind of message at the start of the transfer to ESR 52 stating 
that they have X amount of time to upgrade.



I would feel less queasy about this process, if in the past Mozilla's efforts 
to gracefully wind down an old OS had been graceful. OS X 10.5 got 
decommissioned at Firefox 16.0.2 and never got put on ESR 17. Windows 2000, XP 
RTM, and XP SP1 got decommissioned at Firefox 12.0 and users had to downgrade 
to ESR 10 if they wanted support. Same story with OS X 10.6-10.8 as those OS's 
got decommissioned at Firefox 47.0.1 and users had to downgrade to ESR 45 for 
continued support. This is all further complicated by the fact that Mozilla 
doesn't like to have users cross channels (for obvious reasons like preventing 
bugs and messed up profiles). Mozilla has never to my knowledge moved a user 
base automatically from Release Channel to ESR Channel. Those who wanted 
continued support in the past had to downgrade on their own. Mozilla stores the 
ESR at the following non-obvious URL: 
https://www.mozilla.org/en-US/firefox/organizations/. 



Also, Mozilla doesn't advertise the existence of the ESR Channel. I often feel 
that Mozilla treats its ESR like the red-headed stepchild of all its releases. 
Nightly, Developer Edition, Beta, and Release are all front and center and yet 
the ESR Channel is left in the background. I'm sure more people who want a 
slower release cycle would use the ESR if they knew it existed. Mozilla could 
even differentiate itself from other browser makers with the tag line "Firefox: 
Upgrades at Your Speed, Not the Internet's". Then again, Mozilla isn't the only 
one to pull that trick as apparently Microsoft won't let anyone but enterprise 
customers use Windows 10's slowest upgrade cycle.



Beyond that, I don't like the whole tentative nature of security updates beyond 
the first year. I think Mozilla should follow Microsoft's example and have a 
definitive cutoff date. If that means stating that XP and Vista on ESR 52 will 
be supported no later than the release of ESR 66.2.0. Mozilla should state up 
front that it will support ESR 52 for XP/Vista for 2 years up front so that 
people can plan for its depreciation instead of being left in suspense.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: October 17th to October 21st

[Andrei Vaida]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *October 17**- October 21* (week 42).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus


*RELEASE CHANNEL*
*49.0.2*
ID  Summary Product Component   Is a regression 
Assigned to
1311368 
Video content is not always loaded on NASA Television
Core
Plug-ins
YES NOBODY
1311374 
	The video is blocked after exiting full screen and scrolling the page 
on 32bit builds

Core
Plug-ins
YES NOBODY


*BETA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1310725 
[l10n] "Try it now" text is missing on Learn more page
Firefox
Pocket
NO  NOBODY
1310719 
	Artifacts when clicking Pocket panel with v2 value for 
extensions.pocket.settings.test.panelSignUp

Firefox
Pocket
NO  NOBODY
1310723 
[l10n] "Try it now" text is not centered on the Firefox JA build
Firefox
Pocket
NO  NOBODY
1310928 
[l10n] The "Save to pocket" panel text is misaligned
Firefox
Pocket
NO  NOBODY
1312013 
Download Panel glitches when a download is paused and resumed
Firefox
Downloads Panel
NO  NOBODY
1312020 
Download Panel Glitches when removing an item from History
Firefox Downloads Panel NO  NOBODY
1312024 
	Visual notifications that indicate Pause / Resume are slow as download 
progress advances

Firefox
Downloads Panel
TBD NOBODY
1312032 
Pause and resume a download may cause it to fail
Firefox
Downloads Panel
TBD NOBODY
1312036 
	Download Panel removes all the download entries of the same file at the 
same time

Firefox
Downloads Panel
TBD NOBODY


*AURORA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1310758 
Zoom indicator doesn't always update on tab switching for some sites
Firefox
Location Bar
NO  NOBODY
1311009 
"Share selected devices" button is incorrectly displayed
Firefox
Site Identity and Permissions Panels
NO  NOBODY
1311059 
	Starting with 270%, the zoom level can't be increased anymore with 
other methods than ctrl & mouse wheel

Core
Layout
NO  NOBODY
1311630 
	Hovering over the remaining time from a download displays a static 
information

Firefox
Downloads Panel
NO  NOBODY
1311636 
Download speed is only displayed when hovering
Firefox
Downloads Panel
NO  NOBODY
1311661 
The items downloaded are not truncated accordingly
Firefox Downloads Panel NO  NOBODY
1311665 
After 5 downloads the download pop up is not displayed
Firefox Downloads Panel NO  NOBODY
1311671 
Download panel glitches after clearing downloads from Library
Firefox
Downloads Panel
NO  NOBODY
1311667 
Large Download panel after clearing preview panel
Firefox
Downloads Panel
NO  NOBODY


*NIGHTLY CHANNEL*
none

*ESR CHANNEL*
none

Regards,
Andrei Vaida
Team Lead
SOFTVISION

The content of this communication is classified as SOFTVISION 
Confidential and Proprietary Information.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Gervase Markham]

On 22/10/16 18:12, Ehsan Akhgari wrote:
> Have we considered doing something here to help the user when we block
> this API?  For example, we could check to see whether the site has a TLS
> version 

If there were a reliable way to do this, HTTPS Everywhere would be a
whole lot easier to write and maintain :-) AIUI, it's not as simple as
adding an extra s to the protocol, doing a fetch and seeing if the
response is 2xx.

Gerv


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows XP and Vista Long Term Support Plan

[yuhongbao_386]

On Monday, October 24, 2016 at 3:35:20 AM UTC-7, keithga...@gmail.com wrote:
> On Monday, October 24, 2016 at 3:12:31 AM UTC-5, Gervase Markham wrote:
> > On 22/10/16 10:16, keithgallis...@gmail.com wrote:
> > > My concern is that by killing digital certificate updates and TLS
> > > updates, still in use machines whose main purpose is Internet access
> > > are essentially bricked.
> > 
> > This is a feature, not a bug. If those machines shouldn't be on the
> > Internet, and things happen which keep them off the Internet, then hooray.
> > 
> > Gerv
> 
> Like I've said in previous messages on this thread, I agree that XP and Vista 
> should be placed on ESR 52, but I'm worried about those people who don't have 
> access to tech support at home (friends, family, a tech store, etc.) to help 
> them with the next steps of replacing their old machine. It would be good if 
> Mozilla had some kind of message at the start of the transfer to ESR 52 
> stating that they have X amount of time to upgrade.
> 
Feel free to reopen https://bugzilla.mozilla.org/show_bug.cgi?id=1059840 when 
ready.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows XP and Vista Long Term Support Plan

[Eric Rescorla]

This seems to assume facts not in evidence, namely that people will stop
using those
machines rather than just living with whatever the last version we updated
them to.

Do we have any data that shows that that's true?

-Ekr


On Mon, Oct 24, 2016 at 1:12 AM, Gervase Markham  wrote:

> On 22/10/16 10:16, keithgallis...@gmail.com wrote:
> > My concern is that by killing digital certificate updates and TLS
> > updates, still in use machines whose main purpose is Internet access
> > are essentially bricked.
>
> This is a feature, not a bug. If those machines shouldn't be on the
> Internet, and things happen which keep them off the Internet, then hooray.
>
> Gerv
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows XP and Vista Long Term Support Plan

[Peter Dolanjski]

While this doesn't definitively answer your question, it may provide some
insight:
We ran a survey of Chrome XP users (N=819) after Chrome's end of life
message was shown in the product (English only).  The results showed:

   -

   About half the sample plan to continue using Chrome on XP without
   support/updates
   -

   Almost 40% say they will either update Windows, their computer, or
   switch operating system (OS)
   - About 14% overall open to switching browsers, more than half of those
   interested in Firefox

Because this is self reported, it is hard to say how many users will
actually follow through.  I can say that even though 7% said they'd switch
to Firefox, we saw zero evidence (in downloads or ADIs) that they actually
did.

The final data point I have is that NetMarketShare reports that Chrome's
proportion of users on XP users hovered around 13% for almost a year.  Come
May, 2016 (month after Chrome XP EOL), they dropped to 11%.  In the same
period, Firefox stayed relatively even.  We'll likely need to keep tracking
the data to see where they go after a year, but I think it's safe to say
that most users won't seek out an alternative and will continue using the
product.


Peter


On Mon, Oct 24, 2016 at 1:44 PM, Eric Rescorla  wrote:

> This seems to assume facts not in evidence, namely that people will stop
> using those
> machines rather than just living with whatever the last version we updated
> them to.
>
> Do we have any data that shows that that's true?
>
> -Ekr
>
>
> On Mon, Oct 24, 2016 at 1:12 AM, Gervase Markham  wrote:
>
> > On 22/10/16 10:16, keithgallis...@gmail.com wrote:
> > > My concern is that by killing digital certificate updates and TLS
> > > updates, still in use machines whose main purpose is Internet access
> > > are essentially bricked.
> >
> > This is a feature, not a bug. If those machines shouldn't be on the
> > Internet, and things happen which keep them off the Internet, then
> hooray.
> >
> > Gerv
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Ehsan Akhgari]

On 2016-10-24 4:14 AM, Gervase Markham wrote:
> On 22/10/16 18:12, Ehsan Akhgari wrote:
>> Have we considered doing something here to help the user when we block
>> this API?  For example, we could check to see whether the site has a TLS
>> version 
> 
> If there were a reliable way to do this, HTTPS Everywhere would be a
> whole lot easier to write and maintain :-) AIUI, it's not as simple as
> adding an extra s to the protocol, doing a fetch and seeing if the
> response is 2xx.

I suppose we can use the HTTPS Everywhere ruleset for this purpose,
assuming it's something we can (and want to) ship?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Adam Roach]

I'm hearing general agreement that we think turning this off is the 
right thing to do; that maintaining compatibility with Chrome's behavior 
is important (since that's what existing code will presumably be tested 
against); and -- as bz points out -- we don't want to throw an exception 
here for spec compliance purposes. I propose that we move forward with a 
plan to immediately deny permission in non-secure contexts. Kan-Ru's 
proposal that we put this behind a pref seems like a good one -- that 
way, if we discover that something unexpected happens in deployment, 
it's a very simple fix to go back to our current behavior.


I would be hesitant to over-analyze additional complications, such as 
https-everywhere or user education on this topic. We are, after all, 
simply coming into alignment with the rest of the web ecosystem here.


/a

On 10/22/16 12:05, Ehsan Akhgari wrote:

On 2016-10-22 10:16 AM, Boris Zbarsky wrote:

On 10/22/16 9:38 AM, Richard Barnes wrote:

I'm not picky about how exactly we turn this off, as long as the
functionality goes away.  Chrome and Safari both immediately call the
error
handler with the same error as if the user had denied permission.  We
could
do that too, it would just be a little more code.

Uh...  What does the spec say to do?

It seems like the geolocation spec just says the failure callback needs
to be called when permission is defined, with the PERMISSION_DENIED
code, but doesn't mention anything about non-secure contexts.  The
permissions spec explicitly says that geolocation *is* allowed in
non-secure contexts .
The most relevant thing I can find is
, which
is an implementation consideration.  But as far as I can tell, this is
not spec'ed.


Your intent, and the whole "sites that would break are already broken"
thing sounded like we were going to match Chrome and Safari behavior; if
that was not the plan you really needed to explicitly say so!

Yes, indeed.  It seems that making Navigator.geolocation [SecureContext]
is incompatible with their implementation.


We certainly should not be shipping anything that will change behavior
here to something _different_ from what Chrome and Safari are shipping,
assuming they are shipping compatible things.  Again, what does the spec
say to do?

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



--
Adam Roach
Principal Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Richard Barnes]

On Mon, Oct 24, 2016 at 6:29 PM, Adam Roach  wrote:

> I'm hearing general agreement that we think turning this off is the right
> thing to do; that maintaining compatibility with Chrome's behavior is
> important (since that's what existing code will presumably be tested
> against); and -- as bz points out -- we don't want to throw an exception
> here for spec compliance purposes. I propose that we move forward with a
> plan to immediately deny permission in non-secure contexts. Kan-Ru's
> proposal that we put this behind a pref seems like a good one -- that way,
> if we discover that something unexpected happens in deployment, it's a very
> simple fix to go back to our current behavior.
>

This plan sounds fine to me.  Thanks for summarizing, Adam.



> I would be hesitant to over-analyze additional complications, such as
> https-everywhere or user education on this topic. We are, after all, simply
> coming into alignment with the rest of the web ecosystem here.
>

+1

--Richard



>
> /a
>
>
> On 10/22/16 12:05, Ehsan Akhgari wrote:
>
>> On 2016-10-22 10:16 AM, Boris Zbarsky wrote:
>>
>>> On 10/22/16 9:38 AM, Richard Barnes wrote:
>>>
 I'm not picky about how exactly we turn this off, as long as the
 functionality goes away.  Chrome and Safari both immediately call the
 error
 handler with the same error as if the user had denied permission.  We
 could
 do that too, it would just be a little more code.

>>> Uh...  What does the spec say to do?
>>>
>> It seems like the geolocation spec just says the failure callback needs
>> to be called when permission is defined, with the PERMISSION_DENIED
>> code, but doesn't mention anything about non-secure contexts.  The
>> permissions spec explicitly says that geolocation *is* allowed in
>> non-secure contexts .
>> The most relevant thing I can find is
>> , which
>> is an implementation consideration.  But as far as I can tell, this is
>> not spec'ed.
>>
>> Your intent, and the whole "sites that would break are already broken"
>>> thing sounded like we were going to match Chrome and Safari behavior; if
>>> that was not the plan you really needed to explicitly say so!
>>>
>> Yes, indeed.  It seems that making Navigator.geolocation [SecureContext]
>> is incompatible with their implementation.
>>
>> We certainly should not be shipping anything that will change behavior
>>> here to something _different_ from what Chrome and Safari are shipping,
>>> assuming they are shipping compatible things.  Again, what does the spec
>>> say to do?
>>>
>>> -Boris
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
> --
> Adam Roach
> Principal Engineer, Mozilla
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Boris Zbarsky]

On 10/24/16 6:29 PM, Adam Roach wrote:

and -- as bz points out -- we don't want to throw an exception
here for spec compliance purposes.


Actually, what I wanted to say is that if we think all browsers should 
implement some behavior here then we should get the spec changed to say 
so.  Shipping the "always deny if non-secure" behavior is technically 
spec compliant, in the same way that always denying, period, is 
technically spec-compliant, but all that tells us is that the spec in 
its current state isn't very good at achieving interoperability.


So once we figure out what the behavior we plan to implement is, we 
should ensure that we raise a spec issue to get that behavior standardized.


I do not yet have a strong opinion on whether we should change to the 
Chrome behavior, nor how to message this "we're going to break some of 
your sites" bit to our users.


-Boris

P.S. It's entirely possible that for the specific case of SF transit no 
one is using the website to start with and everyone is using some native 
app instead.  :(  Or at least that the Chrome users are doing that, and 
that Firefox users will end up doing so too.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform