Re: navigator.clipboard
Generally speaking, I find it really hard to reason about what we should do regarding clipboard events and drag'n'drop events without taking a larger look at the sad story that rich-text-editing on the web is today. It seemed like there was some really promising explorations happening for a while regarding developing a better API than the current contentEditable behavior. Did that go anywhere? / Jonas On Thu, Mar 10, 2016 at 6:57 AM, Hallvord Reiar Michaelsen Steen wrote: > Hi dev-platform-people, > while editing the clipboard API spec [1] it's sometimes been suggested > to forget about the old slightly cranky API and start fresh. I haven't > had much response from implementors when such ideas came up on > public-webapps, but here's an interesting E-mail from Lucas Garron at > Google who has drafted a document that might turn into a spec for a > better clipboard API. > > I've been allowed to circulate this and ask which developers at > Mozilla might want to be involved in giving feedback on and perhaps > eventually implement such a draft spec. See Lucas's E-mail and the > linked draft below. > -Hallvord > > [1] https://w3c.github.io/clipboard-apis/ > > > -- Forwarded message -- > From: Lucas Garron > Date: Wed, Mar 9, 2016 at 4:16 AM > Subject: navigator.clipboard > To: hst...@mozilla.com > Cc: Daniel Cheng > > > Hello Hallvord, > > I'm a security engineer from Chrome who was slightly involved in > bringing text copying to the open web in Chrome. (Daniel Cheng, CCed, > did most of the hard work.) After introducing copying, we punted on > the topic of image formats, pasting, and clipboard listening, but it > has recently come up again. > > At this point, I'm strongly interested in exploring the possibility of > "getting things right" by introducing a fresh clipboard API, which I'm > tentatively referring to as "navigator.clipboard" (although > window.clipboard would be fine, too ;-). > > I know that it can be a common fallacy to start over on part of the > web platform, but document.execCommand() has a *lot* of baggage from > its designMode origins and it seems you yourself have wondered whether > browsers should consider something else. > We're seeing is a mounting desire to support more clipboard features > on the open web, and I think now is the time to consider a > straightforward-to-use API that is asynchronous: > - We want to transcode image formats for security, but this would > block a synchronous API. > - Paste will require a permission prompt in Chrome, which is much more > straightforward for Promise-based API. > > I've started a very drafty proposal, mostly focused on historical > context and reasons to start fresh. > > Do you have time and interest in collaborating to adapting the > clipboard API spec to a fresh clipboard API? > > There are teams at Google with an active interest (e.g. Chrome Remote > Desktop, Google Docs) in bringing clipboard paste/listening to the > open web whom I'd like to bring in to lead an effort from the Google > side, but I wanted to ask you early in the process. > > Thanks, > »Lucas > ___ > 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: navigator.clipboard
On Fri, Mar 11, 2016 at 8:57 AM, Jonas Sicking wrote: > It seemed like there was some really promising explorations happening > for a while regarding developing a better API than the current > contentEditable behavior. Did that go anywhere? http://w3c.github.io/editing/ ? It's still going strong - well, at least the specs are being worked on, I have no idea if implementation work has started anywhere, maybe specs are not quite ready to call for implementations yet. -HR ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: TV Control Working Group
On Thursday 2016-03-10 02:17 -0800, Jonas Sicking wrote: > On Wed, Mar 9, 2016 at 11:53 PM, L. David Baron wrote: > > Although we've participated in the development of this work in the > > community group, this is an area that we're becoming less involved > > in. > > > > We're also concerned about the general applicability of this work > > to the Web. Our own use of the subset of this API that we > > implement has been restricted to privileged apps on Firefox OS, > > and we're not aware of how it could fit in to the Web's security > > model. > > My personal opinion is that this API is still quite interesting for > TV-products. And that it fits the security model of the web. It's much > less privacy sensitive than getUserMedia or geolocation for example, > and so could use the same security model. The fact that we restricted > it to privileged apps I think was overly cautious. OK, I suppose it would at least need a good bit of interaction with UI for the user to grant permission, but the API seems sufficiently promise-based that that seems realistic. (Or do others disagree? If so, why?) > However, I don't think that it's high enough priority that it's > something that we should invest in at this time. > > So I would skip the second paragraph and instead add "at this time" to > the end of the first. OK, I'll submit the first paragraph. (I have another week, until March 18, to change the response if needed.) -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: W3C WebAppSec credentialmanagement API
Am Freitag, 11. März 2016 05:27:34 UTC+1 schrieb Martin Thomson: > On Fri, Mar 11, 2016 at 5:56 AM, Axel Nennker wrote: > > no password generation help by the UA > > I agree with MattN here, not doing this eliminates much of the > advantage of having a password manager. Or do you have a plan to rely > on sites doing that with CredentialContainer.store()? That doesn't > sound optimal to me. The questions is whether password generation should be part of the standard. The login manager / Firefox can still add password generation. I am not per se against adding password generation to the standard but there should be a PR that WebAppSec agrees on quickly. Support by major / popular sites would help. I fear that a password-complexity-and-renewal-policy-description-language is something that grows out of hand easily. The spec should focus on simple-and-useful features. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Setting property on the element is no longer working on Firefox 45
On Thursday, March 10, 2016 at 2:50:10 PM UTC-5, Kris Maglione wrote: > On Thu, Mar 10, 2016 at 10:44:24AM -0800, Devan Shah wrote: > >This happens in side extension only (works fine on web standalone), i will > >try to extract a simple reproducible scenario. > > > >Is there any way to simulate a extension env on web? > > If your problem is happening in an extension, then filing a bug > and attaching a testcase add-on is your best bet. > > If I had to guess based on what you've told us so far, I'd say > your problem has something to do with X-ray security > wrappers[1]. In general, properties that you add to X-ray > wrappers aren't visible to code running in other globals. I.e., > if you're accessing a web page from an SDK content script, your > view of the DOM nodes are different from the view the web page > sees. This also has implications for properties that you add to > prototypes. > > I don't know of any changes that would have significantly > changed the behavior in 45 vs previous versions, though, so a > testcase would be useful. > > [1]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Xray_vision Thanks Kris, I will take a look at Xray_vision and see if I can use it to create a simple reproducible testcase ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Setting property on the element is no longer working on Firefox 45
On Thursday, March 10, 2016 at 2:42:14 PM UTC-5, Ted Mielczarek wrote: > On Thu, Mar 10, 2016, at 01:23 PM, Devan Shah wrote: > > hello > > > > When I set a custom property such as element.listofSomething = [] and > > then build the list and add it back to the same element. Then this > > element is passed to a function, now in that function I am no longer to > > access this property that I added to the function. > > > > Was there any sort of changes that would impact this? > > > > Also if I make use of Element.prototype to set a custom variable and try > > to access it for an element it is not available any more. IS there > > something that I am missing. (note this is when inside a plugin) > > FYI, I don't know what your particular bug is, but setting custom > properties on DOM elements is called "expandos", which might help you > file a more useful bug report: > https://developer.mozilla.org/en-US/docs/Glossary/Expando > > -Ted Thanks Ted, I will take a look at this. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: W3C WebAppSec credentialmanagement API
On Thursday, March 10, 2016 at 11:27:34 PM UTC-5, Martin Thomson wrote:
> On Fri, Mar 11, 2016 at 5:56 AM, Axel Nennker wrote:
> > no password generation help by the UA
>
> I agree with MattN here, not doing this eliminates much of the
> advantage of having a password manager. Or do you have a plan to rely
> on sites doing that with CredentialContainer.store()? That doesn't
> sound optimal to me.
I think the idea would be something like:
```
var pass = /* generate a long random password */;
var cred = new PasswordCredential({password: pass});
navigator.credentials.store(cred);
```
So having the API as an imperative interface to the password manager doesn't do
the work for you, but (ISTM) makes it more appealing to do so, since you have
more assurance that the user is never going to have to see it.
That does raise the question, however, of how such a credential differs from,
say:
* A cookie
* A random nonce in localStorage/IDB
* A non-extractable WebCrypto key
By which I mean that if a website wants to verify that it is loaded in the same
browser as before, it already has a variety of ways to do so, some of which
offer better anti-theft properties than these Credential objects. Presumably
the fact that these are not being used means that the site wants some
indication that it has the right *user*, not just the right browser. In which
case, generating a long random password is not so useful.
--Richard
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: MacOS 10.6-10.8 support
On 3/10/2016 5:25 PM, Mike Hommey wrote: It's unfair to mention those populations by percentage of the global Firefox population. Why do you think this is unfair? This is about making the best use of our limited engineering/testing/QA resources, and so what really matters is the total impact, not just the impact relative to the mac population. Dolske answered with more details about the numbers. On 3/10/2016 6:38 PM, Nils Ohlmeier wrote: Excuse my ignorance, but what means “deprecate support” exactly? I’m only asking because of the opposing reply’s so far. I’m assuming it means we stop testing and building/releasing for these. Would it be a possible alternative to turn of the tests, but continue to build and release unsupported builds? We intend to do the following things: * add version checking to the builds so that they refuse to run on these versions of MacOS * stop doing any software testing on these versions of MacOS * stop automated testing on Mac 10.6 As soon as we stop testing, we are going to break things. We shouldn't be willing to call things "Firefox" that we aren't proud of, which includes real testing. On 3/10/2016 6:49 PM, Kyle Huey wrote: Why can't we just not ship e10s to these users? We have a number of other populations we're not shipping to, at least for now. We did explicitly consider this option and ultimately rejected it. It would potentially buy us at least one more ESR cycle until next January. After that point we want e10s to be the only configuration. It comes at the cost of ignoring known issues already as well as a nontrivial amount of testing. Ultimately we don't believe this is the right tradeoff. It also prevents us making progress on other areas such non-universal builds. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: W3C WebAppSec credentialmanagement API
On Fri, Mar 11, 2016 at 6:08 PM, wrote: > That does raise the question, however, of how such a credential differs from, > say: > > * A cookie > * A random nonce in localStorage/IDB > * A non-extractable WebCrypto key The idea is that these are all less persistent. When you clear storage/cookies, you don't delete password manager entries. (Which is also why store() requires UI, if I remember correctly.) -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: MacOS 10.6-10.8 support
On Fri, Mar 11, 2016 at 12:20:30PM -0500, Benjamin Smedberg wrote: > We intend to do the following things: > > * add version checking to the builds so that they refuse to run on these > versions of MacOS If we change the macos target version, that's not possible. The resulting binaries can't even be loaded by the dynamic linker on 10.6. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: MacOS 10.6-10.8 support
We've had this conversation several times in the last few years and I think I've finally figured out why it has always felt subtly wrong. Our share of users on older platforms is disproportionally high compared to the market in general because of our decline in market share. People who don't want to upgrade their OS generally don't want to "upgrade" their browser to the shiny new "chrome" thing the kids are talking about either. It is a symptom of a larger problem and it seems like we are continually hiding from that problem instead of tackling it head-on. We should be aggressively cutting support for niche markets and spending that effort to increase our market share where it counts: where it's growing rather than rapidly shrinking. Telling 1.2% of our (admittedly small) market share to, effectively, GTFO, is pretty scary; however, I think the alternative is to simply fail as a project as we chase our users-by-default into more and more niche markets. If we can't use our resources to re-capture 1.2% of the market among people who have modern computers and no obligation to love us, then maybe we've already failed. We need to drop support for OSX 10.8 and Windows Vista yesterday, not next year. We need to cut our losses and ship E10S while we're still relevant. We need to be the browser that works best on Android and Windows 10, not the browser that happens to already be installed. My 2 cents, :terrence On Fri, Mar 11, 2016 at 9:20 AM, Benjamin Smedberg wrote: > > > On 3/10/2016 5:25 PM, Mike Hommey wrote: > >> >> It's unfair to mention those populations by percentage of the global >> Firefox population. >> > > Why do you think this is unfair? This is about making the best use of our > limited engineering/testing/QA resources, and so what really matters is the > total impact, not just the impact relative to the mac population. > > Dolske answered with more details about the numbers. > > On 3/10/2016 6:38 PM, Nils Ohlmeier wrote: > >> Excuse my ignorance, but what means “deprecate support” exactly? >> >> I’m only asking because of the opposing reply’s so far. I’m assuming it >> means we stop testing and building/releasing for these. Would it be a >> possible alternative to turn of the tests, but continue to build and >> release unsupported builds? >> > We intend to do the following things: > > * add version checking to the builds so that they refuse to run on these > versions of MacOS > * stop doing any software testing on these versions of MacOS > * stop automated testing on Mac 10.6 > > As soon as we stop testing, we are going to break things. We shouldn't be > willing to call things "Firefox" that we aren't proud of, which includes > real testing. > > > > On 3/10/2016 6:49 PM, Kyle Huey wrote: > >> >> Why can't we just not ship e10s to these users? We have a number of other >> populations we're not shipping to, at least for now. >> > > We did explicitly consider this option and ultimately rejected it. It > would potentially buy us at least one more ESR cycle until next January. > After that point we want e10s to be the only configuration. It comes at the > cost of ignoring known issues already as well as a nontrivial amount of > testing. Ultimately we don't believe this is the right tradeoff. It also > prevents us making progress on other areas such non-universal builds. > > --BDS > > > ___ > 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 deprecate: MacOS 10.6-10.8 support
On Fri, Mar 11, 2016 at 9:20 AM, Benjamin Smedberg wrote: > On 3/10/2016 5:25 PM, Mike Hommey wrote: >> It's unfair to mention those populations by percentage of the global >> Firefox population. > > Why do you think this is unfair? This is about making the best use of our > limited engineering/testing/QA resources, and so what really matters is the > total impact, not just the impact relative to the mac population. I agree that looking at the total number of users is the correct way to think about this. There is some risk from a PR perspective though. I.e. headlines that say "Firefox drops 25% of Mac users" would be unfortunate. > On 3/10/2016 6:49 PM, Kyle Huey wrote: >> Why can't we just not ship e10s to these users? We have a number of other >> populations we're not shipping to, at least for now. > > We did explicitly consider this option and ultimately rejected it. It would > potentially buy us at least one more ESR cycle until next January. After > that point we want e10s to be the only configuration. It comes at the cost > of ignoring known issues already as well as a nontrivial amount of testing. > Ultimately we don't believe this is the right tradeoff. It also prevents us > making progress on other areas such non-universal builds. My impression is that non-e10s is certainly something that we'll want to get rid of, but that we are not certain on what timeline it'll be possible. Experience shows that big undertakings like that more often take longer than expected, than go quicker than expected. If we can support these users for another year, then that's certainly a non-trivial benefit in and of itself. And it might also give users time to migrate to more modern hardware. Obviously, if don't think that we can support these users anyway, due to already existing issues, then it could still be worth dropping them. However "we're going to drop non e10s support in a year anyway" doesn't seem like a reason to drop these users now. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: GCC 4.8 is now the minimum version required
Hi, Assuming it sticks, GCC 4.8 is now the minimum GCC version required to build Firefox/Gecko. Details in bug 1175546, most notably comment 2. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: MacOS 10.6-10.8 support
On Fri, Mar 11, 2016 at 9:20 AM, Benjamin Smedberg wrote: > > > On 3/10/2016 5:25 PM, Mike Hommey wrote: > >> >> It's unfair to mention those populations by percentage of the global >> Firefox population. >> > > Why do you think this is unfair? This is about making the best use of our > limited engineering/testing/QA resources, and so what really matters is the > total impact, not just the impact relative to the mac population. > The reason for considering benefits of populations relative to their own OS are because there are two kinds of things we get out of platform support. One is greater impact resulting from a higher overall number of users. The other is other strategic benefits we get out of platform support like on Linux where user numbers are low, but gecko and firefox tootling and testing developer contributions are relatively high. For Mac there is a possible web dev connection that's of possible strategic value with higher concentration of web devs on that platfor that help keep sites working well for large numbers of others. > > Dolske answered with more details about the numbers. > Dolske showed some numbers that reflects where in the decline in previous Mac cycles that we removed support, but that could or could not be related to our current problem of trying to find ways to stablize and stop the decline of users. Keeping these releases supported around just a bit longer than google gives people incentive to come back and try firefox. Just the thing we want to happen. If I look a a view of the numbers relative to all current Mac users it looks like 10.8 has the highest value (15% of all current Mac Users) for keeping around just a bit longer if their is any possible way to do that. The others are in the noise. Some one should check these numbers and see if they look right. Version % of all current Mac users as of back in Nov. which is the latest data I can easily get my hands on to play with. Mac10.8.00.1500 Mac10.7.00.0004 Mac10.7.40.0001 Mac10.7.10.0001 Mac10.7.30.0001 Mac10.6.00.0003 > > On 3/10/2016 6:38 PM, Nils Ohlmeier wrote: > >> Excuse my ignorance, but what means “deprecate support” exactly? >> >> I’m only asking because of the opposing reply’s so far. I’m assuming it >> means we stop testing and building/releasing for these. Would it be a >> possible alternative to turn of the tests, but continue to build and >> release unsupported builds? >> > We intend to do the following things: > > * add version checking to the builds so that they refuse to run on these > versions of MacOS > * stop doing any software testing on these versions of MacOS > * stop automated testing on Mac 10.6 > > As soon as we stop testing, we are going to break things. We shouldn't be > willing to call things "Firefox" that we aren't proud of, which includes > real testing. > > > > On 3/10/2016 6:49 PM, Kyle Huey wrote: > >> >> Why can't we just not ship e10s to these users? We have a number of other >> populations we're not shipping to, at least for now. >> > > We did explicitly consider this option and ultimately rejected it. It > would potentially buy us at least one more ESR cycle until next January. > After that point we want e10s to be the only configuration. It comes at the > cost of ignoring known issues already as well as a nontrivial amount of > testing. Ultimately we don't believe this is the right tradeoff. It also > prevents us making progress on other areas such non-universal builds. > > --BDS > > > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
