Re: Intent to ship: block audible autoplay media intervention
Hi Chris, Very excited to see Firefox going forward with autoplay blocking. A couple of comments inline. On Tue, 3 Jul 2018, at 19:38, Chris Pearce wrote: > DETAILS: > > We intend to block autoplay of HTMLMediaElement in tabs which haven't > had user interaction. Web authors should assume that they require a user > gesture (mouse click on a "play" button for example) in order to play > audible media. I assume you will not allow autoplay when navigating into the same website? What about iframes? Will they be allowed to autoplay if the main frame is allowed to? Will the feature policy be used instead? > HTMLMediaElements with a "muted" attribute or "volume=0" are still > allowed to play. Chrome and Safari allows autoplay only when the playback is muted. The spec allows side effect for setting `muted = false;`. What will happen for a website that changes the volume from 0 to something else? Also, will autoplay be allowed when the video has no audio track? -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: block audible autoplay media intervention
On Wed, 4 Jul 2018, at 18:22, Chris Pearce wrote: > Hi Mounir, > > Replies inline below... > > > On Thu, Jul 5, 2018 at 2:56 AM, Mounir Lamouri wrote: > > > Hi Chris, > > > > Very excited to see Firefox going forward with autoplay blocking. A couple > > of comments inline. > > > > On Tue, 3 Jul 2018, at 19:38, Chris Pearce wrote: > > > DETAILS: > > > > > > We intend to block autoplay of HTMLMediaElement in tabs which haven't > > > had user interaction. Web authors should assume that they require a user > > > gesture (mouse click on a "play" button for example) in order to play > > > audible media. > > > > I assume you will not allow autoplay when navigating into the same > > website? What about iframes? Will they be allowed to autoplay if the main > > frame is allowed to? Will the feature policy be used instead? > > > > > A gesture in any document in the document hierarchy gesture activates the > top level document, and a document uses the top level document's gesture > activation status to determine whether it can play (our implementation > actually differs a bit, but this is the effective behaviour). Gesture > activation status isn't preserved across navigation. So if the top level > document navigates, the incoming document hierarchy won't be able to > autoplay. If a non-top-level document navigates, the new document in the > iframe will still use the top-level document's gesture activation status, > and so the iframe's new content document will be able to autoplay. With autoplay coming from third party content, do you consider using Feature Policy to block cross origin iframes by default? > > > HTMLMediaElements with a "muted" attribute or "volume=0" are still > > > allowed to play. > > > > Chrome and Safari allows autoplay only when the playback is muted. The > > spec allows side effect for setting `muted = false;`. What will happen for > > a website that changes the volume from 0 to something else? > > > > > > If an HTMLMediaElement starts playing with muted/volume=0 and then script > sets it to unmuted/volume>0, then we'll pause the media. The volume=0 behaviour isn't compatible with Blink and WebKit. Would it be worth only use muted for consistency between browsers? > > Also, will autoplay be allowed when the video has no audio track? > > > > > > > Our autoplay logic ignores whether the media resource has an audio track; > it makes our implementation simpler, and if an author knows a media should > be inaudible, they can set the muted attribute. So a video element playing > a media resource with no audio track and without the muted attribute would > still be blocked. FWIW, WebKit uses the audio track availability and Blink intends to do this at some point. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: block audible autoplay media intervention
On Fri, 6 Jul 2018, at 00:49, Chris Pearce wrote: > On Friday, July 6, 2018 at 3:10:58 AM UTC+12, Mounir Lamouri wrote: > > On Wed, 4 Jul 2018, at 18:22, Chris Pearce wrote: > > > Hi Mounir, > > > > > > Replies inline below... > > > > > > > > > On Thu, Jul 5, 2018 at 2:56 AM, Mounir Lamouri wrote: > > > > > > > Hi Chris, > > > > > > > > Very excited to see Firefox going forward with autoplay blocking. A > > > > couple > > > > of comments inline. > > > > > > > > On Tue, 3 Jul 2018, at 19:38, Chris Pearce wrote: > > > > > DETAILS: > > > > > > > > > > We intend to block autoplay of HTMLMediaElement in tabs which haven't > > > > > had user interaction. Web authors should assume that they require a > > > > > user > > > > > gesture (mouse click on a "play" button for example) in order to play > > > > > audible media. > > > > > > > > I assume you will not allow autoplay when navigating into the same > > > > website? What about iframes? Will they be allowed to autoplay if the > > > > main > > > > frame is allowed to? Will the feature policy be used instead? > > > > > > > > > > > A gesture in any document in the document hierarchy gesture activates the > > > top level document, and a document uses the top level document's gesture > > > activation status to determine whether it can play (our implementation > > > actually differs a bit, but this is the effective behaviour). Gesture > > > activation status isn't preserved across navigation. So if the top level > > > document navigates, the incoming document hierarchy won't be able to > > > autoplay. If a non-top-level document navigates, the new document in the > > > iframe will still use the top-level document's gesture activation status, > > > and so the iframe's new content document will be able to autoplay. > > > > With autoplay coming from third party content, do you consider using > > Feature Policy to block cross origin iframes by default? > > > I won't rule out doing something in the spirit providing a way for sites > to control whether subframes are allowed to autoplay in future, but we > won't be doing it as part of our MVP. To clarify, your MVP will allow subframes to autoplay if the main frame can, right? > > > > > HTMLMediaElements with a "muted" attribute or "volume=0" are still > > > > > allowed to play. > > > > > > > > Chrome and Safari allows autoplay only when the playback is muted. The > > > > spec allows side effect for setting `muted = false;`. What will happen > > > > for > > > > a website that changes the volume from 0 to something else? > > > > > > > > > > > > > > If an HTMLMediaElement starts playing with muted/volume=0 and then script > > > sets it to unmuted/volume>0, then we'll pause the media. > > > > The volume=0 behaviour isn't compatible with Blink and WebKit. Would it be > > worth only use muted for consistency between browsers? > > This code gives me the impression that WebKit does in fact block volume > > 0 media: > https://github.com/WebKit/webkit/blob/2d78ab563d64545ead630115bcd55047d0400fac/Source/WebCore/html/MediaElementSession.cpp#L303 > > So maybe Blink should consider changing to be consistent with other browsers? > ;) That's interesting. We spec'd something in HTML and Safari did not mention this. It's not in their documentation nor ours. What's the benefit of allowing volume=0 to autoplay? > > > > Also, will autoplay be allowed when the video has no audio track? > > > > > > > > > > > > > > > Our autoplay logic ignores whether the media resource has an audio track; > > > it makes our implementation simpler, and if an author knows a media should > > > be inaudible, they can set the muted attribute. So a video element playing > > > a media resource with no audio track and without the muted attribute would > > > still be blocked. > > > > FWIW, WebKit uses the audio track availability and Blink intends to do this > > at some point. > > > I actually implemented this, landed it, and then ended up reverting it. > > The main problem here is if HTMLMediaElement.play() is called before the > load algorithm has reached readyState>=HAVE_MET
Re: Intent to ship: block audible autoplay media intervention
On Fri, 6 Jul 2018, at 15:35, Chris Pearce wrote: > On Saturday, July 7, 2018 at 5:04:28 AM UTC+12, Mounir Lamouri wrote: > > On Fri, 6 Jul 2018, at 00:49, Chris Pearce wrote: > > > On Friday, July 6, 2018 at 3:10:58 AM UTC+12, Mounir Lamouri wrote: > > > > On Wed, 4 Jul 2018, at 18:22, Chris Pearce wrote: > > > > > > > HTMLMediaElements with a "muted" attribute or "volume=0" are still > > > > > > > allowed to play. > > > > > > > > > > > > Chrome and Safari allows autoplay only when the playback is muted. > > > > > > The > > > > > > spec allows side effect for setting `muted = false;`. What will > > > > > > happen for > > > > > > a website that changes the volume from 0 to something else? > > > > > > > > > > > > > > > > > > > > > > If an HTMLMediaElement starts playing with muted/volume=0 and then > > > > > script > > > > > sets it to unmuted/volume>0, then we'll pause the media. > > > > > > > > The volume=0 behaviour isn't compatible with Blink and WebKit. Would it > > > > be worth only use muted for consistency between browsers? > > > > > > This code gives me the impression that WebKit does in fact block volume > > > > 0 media: > > > https://github.com/WebKit/webkit/blob/2d78ab563d64545ead630115bcd55047d0400fac/Source/WebCore/html/MediaElementSession.cpp#L303 > > > > > > So maybe Blink should consider changing to be consistent with other > > > browsers? ;) > > > > That's interesting. We spec'd something in HTML and Safari did not mention > > this. It's not in their documentation nor ours. What's the benefit of > > allowing volume=0 to autoplay? > > > Setting volume to 0 is another easy way to make videos inaudible, and we > want inaudible video to be able to autoplay. So I'd flip that question > around and ask why you think volume=0 video should not autoplay but a > video without an audio track should? Both are inaudible. `muted` and the presence of an audio track clear distinguishable signals as they are boolean and declarative. A video that has volume 0 could be for various reasons. Furthermore, requiring `muted` or `volume` seems slightly odd as they both apply to the HTML content while the audio track metadata is at a different level so can offer benefits if for example, modifying the content is possible but not the page. FWIW, we could add this in Blink if it can help with x-browser compat but I've never heard of a website asking for this nor did I see articles suggesting using volume=0 even from Apple. Given that it would require the website to set `video.volume = 0;` in script, it is less powerful than `muted` that can be used as a content attribute too. > > > > > > Also, will autoplay be allowed when the video has no audio track? > > > > > > > > > > > > > > > > > > > > > > > Our autoplay logic ignores whether the media resource has an audio > > > > > track; > > > > > it makes our implementation simpler, and if an author knows a media > > > > > should > > > > > be inaudible, they can set the muted attribute. So a video element > > > > > playing > > > > > a media resource with no audio track and without the muted attribute > > > > > would > > > > > still be blocked. > > > > > > > > FWIW, WebKit uses the audio track availability and Blink intends to do > > > > this at some point. > > > > > > > > > I actually implemented this, landed it, and then ended up reverting it. > > > > > > The main problem here is if HTMLMediaElement.play() is called before the > > > load algorithm has reached readyState>=HAVE_METADATA, you won't know > > > whether the media you're loading has audio tracks. > > > > > > If you hit this case, you have two options; decide whether to block > > > immediately based on incomplete information, or return the promise and > > > wait until you reach loadedmetadata before deciding whether to play. > > > > > > If you decide based on incomplete information you become racy; the > > > decision you make on incomplete information may contradict the decision > > > you'd make based on more complete information when the load is further > > > along, and network loads are inh
Re: Intent to Implement and Ship: Permissions API
On Tue, 25 Aug 2015, at 07:57, Anne van Kesteren wrote: > On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas > wrote: > > Summary: The Permissions API allows a web application to be aware of > > the status of a given permission, to know whether it is granted, > > denied or if the user will be asked whether the permission should be > > granted. > > I'm not a big fan of this API. > > 1) It doesn't map well to what browsers do internally. Rather than > simple strings it uses some kind of convoluted dictionary design. Browsers internal implementation can change. The API will have to stay as it is in the long run. It's better to have an flexible API that would allow different implementation strategies. > 2) It would be better to simply expose the permission status of a > particular feature near a particular feature. If you want to know > whether geolocation is already granted you should just be able to call > navigator.geolocation.permission() or some such. This isn't working for some APIs. For example, MIDI has a very basic navigator.requestMIDIAccess(). Should we start having navigator.queryMidiAccess()? > 3) It seems the API is evolving in ways to also request permission > without then directly using that permission. It's not clear that is a > good idea. This is something that is already doable. If a webpage calls navigator.geolocation.getCurrentPosition(), it doesn't need to do anything with the position (this can apply to roughly any API). The Notififcations API has an explicit call for requesting too. Furthermore, allowing requests will open some new possibilities like requesting a 'paste' permission which can't be done today. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement and Ship: Permissions API
On Wed, 2 Sep 2015, at 03:50, Ehsan Akhgari wrote:
> On 2015-09-01 9:57 PM, Jonas Sicking wrote:
> > But I agree that we should make it clear that we do not intend to
> > implement a request API.
>
> There is actually a valid use case for a request API. It has become
> clear that we need to expose pasting functionality to the Web, and the
> most natural way of doing so is document.execCommand("paste"). This
> operation however cannot be exposed without permission because of
> privacy reasons. And this is an API where modifying it to add support
> for requesting permission doesn't make sense.
>
> AFAIK right now the Chrome team is experimenting with creating a
> solution for this use case using the request API. If they manage to
> come up with a good UX, I think we need to implement it (at least for
> the "paste" permission) as well.
Correct.
I don't want to derail the thread and it should probably be a question
for later but I don't understand why websites shouldn't be able to
request permissions when Notifications allows it, Persistent Storage
(latest version) allows it and for the other API it is possible to
actually write a polyfill to request permissions (eg.
navigator.geolocation.getCurrentPosition(function(){}) actually request
the permission). We are just making web developers life harder by
requiring them to request permission indirectly.
There are other reasons why request() would benefit the platform. For
example, being able to request permission for a feature that is used in
some kind of Workers (where permissions can't be requested). Though,
again, I don't want to derail the thread.
-- Mounir
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
Note that Chrome 46 has a way to work around the white screen while a page load using a new property in the Manifest. If a website added to the homescreen on Chrome Android has a background_color information, it will be used while the page loads. After Chrome gets the first paint following a non-empty layout, it will remove that plain colour and switch to whatever the page has ready. It allows websites to be constructed as websites and not rely on that splashscreen feature that might or might not be present (given the UA and the current context) and also keep the principle of quick first paint. Would using a similar system (ie. background_color from the Manifest) help you here? -- Mounir On Wed, 7 Oct 2015, at 14:17, vnico...@mozilla.com wrote: > I also forgot to say that the proposed solution does not help for cases > like bug 1199674 afaict. > ___ > 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: Allowing web apps to delay layout/rendering on startup
On Fri, 9 Oct 2015, at 16:27, Vivien Nicolas wrote: > On Thu, Oct 8, 2015 at 6:10 PM, Mounir Lamouri wrote: > > > Note that Chrome 46 has a way to work around the white screen while a > > page load using a new property in the Manifest. If a website added to > > the homescreen on Chrome Android has a background_color information, it > > will be used while the page loads. After Chrome gets the first paint > > following a non-empty layout, it will remove that plain colour and > > switch to whatever the page has ready. It allows websites to be > > constructed as websites and not rely on that splashscreen feature that > > might or might not be present (given the UA and the current context) and > > also keep the principle of quick first paint. > > > > > Would using a similar system (ie. background_color from the Manifest) > > help you here? > > > > > I will be happy to use the background_color field in the manifest. It > will > likely help web app pinned to the homescreen. > I also think it will be a great idea to use it to replace the static > black > color that is displayed before applications are launched and try to unify > the experience between installed apps and pinned apps. > > However while I think background_color is useful, the white flash we are > trying to address here is between the splash screen and the app content > beeing loaded. I think, but I may be wrong, that we don't want to have a > 3 > steps startup with: > 1. Black splashscreen with icon > 2. plain background_color instead of a white flash > 3. App content beeing displayed when ready. > > I guess 1. and 2. can be merged. > > Now the issue, if my understanding is correct, Gecko does not have the > notion of firstpaint after a non-empty layout. Which means even if 1. and > 2. are merged we can end up in a situation where you have: > 1./2. background_color with/without icon > 3. white flash > 4. App content beeing displayed when ready. Sorry for misunderstanding. > So basically what I want to add in bug 1211853 (first attachement) is (a > very simple) mechanism to not paint until there is something to paint. > And > from here provide a mechanism for web app to control when first paint > happens without enforcing them to be built a specific way. Did you look into firing the event after there is a non-empty layout or does that come to the same thing as what your patch is doing? Also, it seems unfortunate to have applications hacking around the first paint. As far as speed feeling goes, they would win to show something as soon as possible and handle any post-first paint loading themselves. > An other constraints for application with multi-steps startup is to > display > something as quick as possible to the user and continue their execution > after first paint. As of today there is no way (at least in Gecko, dunno > for Chrome) to know when the UA has painted something on the screen. I > would like to introduce a (moz)firstpaint event so app authors can > optimize > their app to quicly show something on the screen, then wait for the UA to > paint, and then continue their execution. I was talking about a firstpaint even to some Chrome folks earlier this week and I have a TODO to talk with some other folks next week when they will be back from their holidays. So far, the feedback on this idea was fairly positive but I need to make sure there isn't something obvious I'm missing. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On Sat, 10 Oct 2015, at 02:02, zbranie...@mozilla.com wrote: > On Friday, October 9, 2015 at 10:51:54 AM UTC-7, Mounir Lamouri wrote: > > As far as speed feeling goes, they would win to show something as soon > > as possible and handle any post-first paint loading themselves. > > That is unfortunately not consistent with my experience. People tend to > perceive visible progressive as much slower than delayed first-paint in > most scenarios. > > On top of that, it is perceived as a really_bad_ux. I don't think I agree but I don't mean to discuss Firefox OS product decisions. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: window.orientation and orientationchange event
FWIW, this is the usage of window.orientation in the wild recorded by Chrome: https://www.chromestatus.com/metrics/feature/timeline/popularity/285 However, Google's internal tools allow me to see the repartition between platforms and this seen a lot by Chrome Android users. Should we add this to the Screen Orientation specification? -- Mounir On Tue, 20 Oct 2015, at 04:56, Jonas Sicking wrote: > As someone pushing for the ScreenOrientation API, I agree with this > intent nonetheless. > > It *might* be worth warning about this property being inconsistent, > and that it's better for users to use the ScreenOrientation API. But I > think it's really only worth doing if this is something that other > browsers agree to do as well. > > / Jonas > > > On Mon, Oct 19, 2015 at 8:29 PM, William Chen wrote: > > *Summary*: window.orientation returns a value corresponding to the screen > > orientation. The orientationchange event is fired when the orientation of > > the viewport is changed. These features are non-standard but have been > > implemented by other browser vendors on mobile platforms leading to > > widespread usage on major websites. In order to improve web compatibility, > > these features are also going to be implemented by Gecko on mobile > > platforms and we are also working on standardizing the feature. Web authors > > should avoid these features because the values returned by > > window.orientation are unreliable as it means different things across > > different platforms. Instead, authors should use the ScreenOrientation API > > which offers the more functionality and better specified behavior. > > > > *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=920734 > > > > *Link to standard*: https://compat.spec.whatwg.org/#dom-window-orientation > > > > *Platform coverage*: Firefox for Android and Firefox OS. > > > > *Estimated or target release*: Firefox 44 > > > > These features are currently implemented by the stock Android browser, > > Safari on iOS, Chrome for Android and Internet Explorer on Windows Phone. > > ___ > > 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: Removing the Battery Status API?
On Tue, 29 Nov 2016, at 15:17, Boris Zbarsky wrote: > > I understand the privacy concerns, but why can't these be handled similar > > to the Geolocation API? Ask permission to use / user opts in. > > Because prompting users is generally an antipattern. If, as a user, you > got a battery API prompt on every single page (because the trackers on > it were trying to use it), what would be your reaction? There are other solutions that are not prompting. The specification even provide guidance such as returning less granular values or even default values. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Presentation API on Fennec
On Fri, 2 Dec 2016, at 15:09, Boris Zbarsky wrote: > On 12/2/16 6:11 AM, Shih-Chiang Chien wrote: > > We implement 1-UA mode described in spec. Session resumption and many-to-1 > > session is not available in this mode. > . > > Google have release this API on both desktop and Android browser for 2-UAs > > mode (see https://www.chromestatus.com/feature/6676265876586496), which > > allows web page to communicate with Chromecast receiver apps. They are > > implementing 1-UA mode as well, see > > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HZ_ZHEE9oDo > > Just to make sure I understand: > > 1) Google ships "2-UAs" mode. On which platforms? Mobile and Desktop. Chrome Android supports Cast devices. On desktop I believe DIAL is also supported. > 2) We are planning to ship 1-UA mode on Android only, for the moment. > 3) Google is implementing 1-UA mode on desktop only, for the moment. Correct. Intent to ship has been sent on blink-dev. Chrome Android should follow. > Is that a correct summary of the current interop situation? > > If it is, I have some questions: > > A) How are sites expected to make use of this in practice given the > above? > B) If a site is written to Google's 2-UAs implementation, what happens > when it runs in Firefox with the 1-UA implementation? Can it detect > that it's dealing with a 1-UA implementation instead of a 2-UAs one? > Does it need to do such detection? Do sites do it in practice? The answers to these two questions is very similar. The spec allows to pass an array of URLs to the `PresentationRequest` constructor. That will allow developers to pass Chrome Cast, DIAL and HTTP links (usually called 1-UA mode). Potentially also a Firefox OS TV app URL if they are still different from regular HTTP links. Assuming a website only cares for Chrome Cast support (ie. a variation of 2-UA mode), the implementation will expose whether there are available displays to use. Assuming an implementation doesn't support Chrome Cast, the website will believe that there is no device available around, the same way as an implementation supporting the device but without one available. > Do we have any indications from Apple or Microsoft as to whether they > plan to implement this API? Apple has been contributing to the discussions. I would say that they showed interest but as usual, we can't deduce any implementation plans. As far as I know, Microsoft never said anything about this API. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Presentation API on Fennec
On Sat, 10 Dec 2016, at 17:58, Boris Zbarsky wrote: > On 12/5/16 3:20 AM, Mounir Lamouri wrote: > > Correct. Intent to ship has been sent on blink-dev. Chrome Android > > should follow. > > Do you have any idea what the timeframe is? Unfortunately not. My best guestimate is 2017 but that's probably too vague :) > > The answers to these two questions is very similar. The spec allows to > > pass an array of URLs to the `PresentationRequest` constructor. That > > will allow developers to pass Chrome Cast, DIAL and HTTP links (usually > > called 1-UA mode). Potentially also a Firefox OS TV app URL if they are > > still different from regular HTTP links. > > OK, but a website doing this won't work in Chrome Android. So what > would websites actually do in practice? Not sure what you mean wouldn't work. If a website is a good web citizen and uses PresentationRequest with an array of URLs such as ['http://example.com', 'cast://example', 'dial://example', 'mozapp://example' ], Chrome Android will work fine because it will use the "cast://" URL. If a website only uses the 'http://example.com' URL, Chrome Android browsers will appear as if there are no devices available. Either way, the website shouldn't be able to notice the difference. Users might realise that some browsers are able to pick up some devices and some are not. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Presentation API on Fennec
On Mon, 12 Dec 2016, at 04:00, Boris Zbarsky wrote: > On 12/11/16 8:47 AM, Mounir Lamouri wrote: > > On Sat, 10 Dec 2016, at 17:58, Boris Zbarsky wrote: > >> OK, but a website doing this won't work in Chrome Android. So what > >> would websites actually do in practice? > > > > Not sure what you mean wouldn't work. If a website is a good web citizen > > and uses PresentationRequest with an array of URLs such as > > ['http://example.com', 'cast://example', 'dial://example', > > 'mozapp://example' ], Chrome Android will work fine because it will use > > the "cast://" URL. > > I may just be missing something or misunderstanding how the API works... > > Is the 1-UA vs 2-UAs mode thing transparent to the page? Based on the > descriptions of the modes it sounded to me like you can do things in at > least 2-UAs mode that you can't do in 1-UA mode; not sure about vice > versa. So presumably it's not entirely transparent? Or is the idea > that anything that works in 1-UA mode is available in 2-UAs mode and the > APIs are identical for that subset of functionality, so a page that > pretends like it's always working with 1-UA mode will just work with > 2-UAs mode? What specifically do you have in mind when you say that 1-UA mode might lack features? Technically, 1-UA mode is when a page is rendered on the client and sent to the remote device. It's mostly a technical detail because one can't render HTML pages on a Chrome Cast without creating an application, Chrome folks call pure HTML rendering 1-UA mode. It is fairly similar to tab mirroring. I don't think any feature should be lacking except maybe access to the APIs on the other device. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Notice of browser and toolkit theme renamings
On 23/02/13 07:25, Jared Wein wrote:
> Hi,
>
> I wanted to let you all know about bug 842913, of which I just landed the
> patch for on mozilla-inbound.
>
> The goal of the bug is to make the process of working with the /browser and
> /toolkit themes easier for new contributors. The previous names of
> {winstripe,pinstripe,gnomestripe} were never exposed in the product and were
> unclear to new users as to which platforms/environments they targeted.
>
> In toolkit:
> /toolkit/themes/winstripe/ becomes /toolkit/themes/windows/
> /toolkit/themes/pinstripe/ -> /toolkit/themes/osx/
> /toolkit/themes/gnomestripe/ -> /toolkit/themes/linux/
> /toolkit/themes/pmstripe/ -> /toolkit/themes/os2/
> /toolkit/themes/faststripe/ -> (unchanged)
>
> In browser:
> /browser/themes/winstripe/ becomes /browser/themes/windows/
> /browser/themes/pinstripe/ -> /browser/themes/osx/
> /browser/themes/gnomestripe/ -> /browser/themes/linux/
Is themes/linux/ agnostic of the library being used (aka GTK vs QT)?
--
Mounir
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: GTest has landed
On 25/02/13 15:57, Benoit Girard wrote: > Hello dev.platform, > > GTest has landed this weekend on mozilla-central[1]. It should now be > ready for developers to start writing test. It will appear on > tinderbox once it is build off '--enable-tests'. For more details see > the documentation: https://developer.mozilla.org/en-US/docs/GTest Looking forward to use that! Thanks :) -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Storage in Gecko
On 26/04/13 11:17, Gregory Szorc wrote: > Anyway, I just wanted to see if others have thought about this. Do > others feel it is a concern? If so, can we formulate a plan to address > it? Who would own this? As others, I believe that we should use IndexedDB for Gecko internal storage. I opened a bug regarding this quite a while ago: https://bugzilla.mozilla.org/show_bug.cgi?id=766057 We could easily imagine an XPCOM component that would expose a simple key/value storage available from JS or C++ using IndexedDB in the backend. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: packaged apps and origins
On 25/04/13 17:34, Ben Adida wrote:
> Potch has a great proposal: let apps declare a marketplace in their
> manifest. If apps are served from and signed by the marketplace, then
> any origin is okay (after review.) If apps are self-hosted, then the
> only origin allowed is that of the hosting site.
>
> I suggested a tweak to this: if a packaged app is served from
> https://example.com, then it can set an origin of app://example.com, so
> that it is stable but also different from the actual hosted origin.
Jonas and I have been speaking about that a few times and the solution
we though about was to allow privileged applications (aka signed
applications) to specify one origin in the manifest that will have to be
reviewed with the code. However, we should definitely not use
"app://example.com" because that would not be same origin with
"http://example.com"; as Fabrice said. As I see it, this is a terrible
violation to the packaged application security principles but it seems
to be the best compromise.
That means that packaged applications that are not privileged will not
be able to have another origin that app://{guid}.
Also, hosted applications already have an origin so they don't need that
feature.
--
Mounir
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Storage in Gecko
On 26/04/13 20:42, bent wrote: > IndexedDB is our answer for this for JS... C++ folks are still pretty > much on their own! Why? Wouldn't be the idea of such component to make sure it is usable from C++? -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: HTML Working Group
On 22/05/13 03:09, L. David Baron wrote: > On Friday 2013-02-08 14:37 -0800, L. David Baron wrote: >> W3C is proposing a revised charter for the HTML Working Group. >> For more details, see: >> http://lists.w3.org/Archives/Public/public-new-work/2013Feb/0009.html >> http://www.w3.org/html/wg/charter/2012/ >> >> Mozilla has the opportunity to send comments or objections through >> Tuesday, March 12. Please reply to this thread if you think there's >> something we should say. > > A bit of followup here. One of the pieces of feedback I got as part > of the previous round of review was that we should push for at least > allowing *experimentation* with more open document licenses than the > W3C currently allows. As a result, the W3C has proposed a revised > charter with this modification and a few other small modifications > resulting from the review. I've described the rationale for this > and the sequence of events in a bit more detail here: > http://dbaron.org/log/20130522-w3c-licensing > > This means there's currently another charter review period going on, > to review this new charter: > http://lists.w3.org/Archives/Public/public-new-work/2013May/.html > http://www.w3.org/html/wg/charter/2013/ Thank you for doing that David, this is a great step forward :) -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
On 21/06/13 21:45, Andrew Overholt wrote: > I'd appreciate your review feedback. Thanks. Thank you for putting this together. I am going to quote some parts of the document to give some context to my comments. > Note that at this time, we are specifically focusing on new JS APIs > and not on CSS, WebGL, WebRTC, or other existing features/properties. I think the "JS APIs" here is unclear. I think saying "Web APIs" would be more appropriate, assuming this is what you meant. Also, I do not understand why we are excluding CSS, WebGL and WebRTC. We should definitely not make this policy retro-apply so existing features should not be affected but if someone wants to add a new CSS property, it is not clear why this shouldn't go trough this process. > 1. Is the API standardized or on its way to being so? > 2. Declaration of intent > 3. API review > 4. Implementation > 5. Shipping I think 2) should be "Declaration of intent to implement" and we should add an item between 4) and 5) named "Declaration of intent to ship". Those two distinct items are important I believe. > 2. at least two other browser vendors ship a compatible > implementation of this API I will join Henri: "browser vendors" should be "browser engines" and "ship" is too restrictive. If a feature is implemented and available in some version (even behind a flag) with a clear intent to ship it at some point, this should be enough for us to follow. > 3. at least one other browser vendor ships -- or publicly states > their intention to ship -- a compatible implementation of this API > and there is a specification that is no longer at risk of significant > changes, on track to become a standard with an relevant standards > body, and acceptable to a number of applicable parties Actually, with this point, point 2) sounds barely useful. The only situation when we could have 3) applying but not 2) would be if two engines implement a feature that has no specification. > 2. ecosystem- and hardware-specific APIs that are not standard or of > interest to the broader web at that time (or ever) may be shipped in > a way to limit their harm of the broader web (ex. only on a device > or only in specific builds with clear disclaimers about applicability > of exposed APIs). An example of this is the FM Radio API for Firefox > OS. When I read this, I read "It is okay to have Mozilla ship a phone with proprietary APIs". That means that we are okay with Mozilla creating the situation Apple created on Mobile, a situation that Mozilla has been criticising a lot. Shipping proprietary APIs on a specific device is harming the broader Web if that device happens to be one of the most used device out there... > 3. APIs solving use cases which no browser vendor shipping an engine > other Gecko is interested in at that time. In cases such as this, > Mozilla will solicit feedback from as many relevant parties as > possible, begin the standardization process with a relevant standards > body, and create a test suite as part of the standards process. An > example of this is the Push Notifications API. I am not a big fan of that exception. Given how fast paced the Web is nowadays, we could easily put a lot of APIs in that category. Actually, if we ask other vendors what they think about most Firefox OS APIs, we will very likely get no answer. Does that mean that those APIs are good to go? > Declaring Intent > API review > Implementation > Shipping I think some clarifications are needed in those areas. First of all, we should define two kind of "Declaration of intent", one for implementation and one for shipping. Implementation could be a Public Service Announcement aimed to know if anyone strongly objects. In other words, if I want to implement feature foo, I would have to start a thread, explain what I want to do, in which context (platforms) and ask if anyone objects. Then should come the intent to ship email that would be more formal. In my opinion, the reviewing part should be simplified. Intent emails should be reviewed by "dev-platform", not a "API review team". In other words, any one should be able to express its opinion and opinions will be listened based on their technical value, not based on affiliation. The code review should follow the usual rules and the IDL should have a super-review as the current Mozilla rules requires it. Adding a commit hook to dom/webidl/ to make sure that commits have a sr+ would be great to enforce that rule even though it wouldn't prevent all problems. The issue with having "dev-platform" finding a consensus with intent emails is that we might end up in a infinite debate. In that case, we should use the module system and have the module owner(s) of the associated area of code make the decision. If the module owner(s) can't take this decision, we could go upward and ask Brendan to make it. It would be great to have a list of required information for intent emails. A template could be quite helpful. > 1. should we have a joint
Re: Intent to implement: nsIDOMMozIccManager.getCardLockRetryCount
Hi Thomas,
MozICCManager is an API available only for built-in applications on
Firefox OS so it is fine to change it as much as you want.
--
Mounir
On 25/06/13 17:11, Thomas Zimmermann wrote:
> Hi,
>
> I intent to implement an extension to nsIDOMMozICCManager.
>
> When unlocking a SIM card, there is a maximum number of remaining tries.
> The new interface 'getCardLockRetryCount' will allow for reading the
> number of remaining tries for a specific lock. During the unlock
> process, an app can display this information to the user, probably in
> conjunction with a descriptive message (e.g, 'You have 3 tries left.').
>
> interface nsIDOMMozIccManager {
> ...
> nsIDOMDOMRequest getCardLockRetryCount(in DOMString lockType);
> ...
> };
>
> The parameter 'lockType' is a string that names the lock. The result is
> a DOM request. On success, it returns the number of retries in its
> result property; on error it returns a error name. An error happens if
> the given lock type is not known or not supported by the implementation.
>
> There is more detailed documentation in bug 875710, comments 17 and 18 [1].
>
> Any feedback and suggestions are welcome.
>
> Best regards
> Thomas
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=875710#c17
> ___
> 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: Making proposal for API exposure official
On 25/06/13 17:28, Robert O'Callahan wrote: > On Wed, Jun 26, 2013 at 4:15 AM, Mounir Lamouri wrote: > >>> 3. APIs solving use cases which no browser vendor shipping an engine >>> other Gecko is interested in at that time. In cases such as this, >>> Mozilla will solicit feedback from as many relevant parties as >>> possible, begin the standardization process with a relevant standards >>> body, and create a test suite as part of the standards process. An >>> example of this is the Push Notifications API. >> >> I am not a big fan of that exception. Given how fast paced the Web is >> nowadays, we could easily put a lot of APIs in that category. > > I don't see this. Can you give some examples? On Mozilla's side, there are a few APIs that we are pushing and do not interest other vendors for the moment. Most APIs related to Firefox OS. On Google's side, it is harder to find examples because I do not follow that as closely but requestAutocomplete() is an example of an API that Mozilla might not look at for quite some time. On Apple and Microsoft side, they do not anyway express intents before shipping but Apple has a history on Webkit iOS for pushing APIs that sometimes ended up in specs and sometimes just stayed as a Apple-only API. >> Actually, >> if we ask other vendors what they think about most Firefox OS APIs, we >> will very likely get no answer. Does that mean that those APIs are good >> to go? > > If "no answer" means "we don't care about your use cases", then we can't > let that block our progress, because there are always going to be use-cases > we need to solve that no other vendor is currently interested in. I agree that getting blocked because other vendors don't care about our use cases is not a good situation. However, it is easy to push bad APIs because no one had time to look into it and then, when they do, having two competing API which ends up in a mess (IDB vs WebSQL for example). My point is not that we will do that on purpose but we are opening a door to situations like these. Cheers, -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
On 26/06/13 16:59, Ehsan Akhgari wrote: > For whatever it's worth, Blink has made the decision to implement Web > MIDI without receiving any feedback from us (and to the best of my > knowledge from other vendors), I am not sure why implementing something should require that many rules as long as it doesn't ship. > and has also made the decision to ship > requestAutocomplete hoping that Hixie will add it to the spec before it > hits the Chrome release channel. This is not true, they pushed it to Canary-only [1]. This said, I am not sure that we should allow us to have a bad behaviour because we believe other groups have/had that behaviour. > So, are you proposing that we should give feedback on all APIs even if > they're not interesting to us? I'd be fine with that, but I don't think > we can assume that it will be reciprocated. This is a concern I share. [1] https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/requestautocomplete/blink-dev/0TnqLOvC2ZY/Wf_c2GExrCoJ -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
On 26/06/13 18:13, Ehsan Akhgari wrote: > On 2013-06-26 12:17 PM, Andrew Overholt wrote: >> On 26/06/13 11:48 AM, Ehsan Akhgari wrote: >>> On 2013-06-26 11:21 AM, Andrew Overholt wrote: On 24/06/13 05:52 PM, Ehsan Akhgari wrote: > There are two things that I think can use clarification. One is what > we're going to do about "trivial changes"? Do all web facing features > ned to go through this process? I was going to put a blurb about "trivial changes" but thought it would be too hard to define. >> >> Sorry, I was wrong here. I didn't put it in because I intended the >> policy to only cover new APIs. I guess we could say "new APIs or major >> changes to existing APIs" ... > > Well, the policy also mentions enforcement through commit hooks (which I > don't like!) so it at least looks to cover all API changes. It is very easy to do a sr for a trivial change. I very often get sr requests for simple changes by the RIL team. It usually takes me a couple of minutes to open the bug, have a quick look and sr+. The benefit of that is that a few times, I was able to reject some changes that were not needed or not right. The only issue in making sr+ mandatory for trivial changes is that authors might wait too long for simple changes because reviewers are staying behind their review queue. I think this is a general problem we should solve instead of designing other processes around it. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
On 26/06/13 17:08, Andrew Overholt wrote: > On 25/06/13 12:15 PM, Mounir Lamouri wrote: >> Also, I do not understand why we are excluding CSS, WebGL and WebRTC. We >> should definitely not make this policy retro-apply so existing features >> should not be affected but if someone wants to add a new CSS property, >> it is not clear why this shouldn't go trough this process. > > My hope was to get something in place for APIs and then build up to > other web-exposed "things" like CSS, etc. In my opinion, CSS, HTML, DOM, WebGL, WebRTC and other Web APIs should follow that rules. I do not see why CSS, for example, should be an exception. >> "ship" is too restrictive. If a feature is implemented and available in >> some version (even behind a flag) with a clear intent to ship it at some >> point, this should be enough for us to follow. > > I changed it to "at least two other browser engines ship (regardless if > it's behind a flag or not in their equivalent of beta or release) -- a > compatible implementation of this API ". How's that? I don't want to > see us basing our decision to ship on another engine's use of their > nightly equivalent for experimentation (whether this happens right now > or not). Am I worried for no reason? As Henri said, we should make sure that there is a genuine intent to ship if a feature is implemented in a browser (even behind a flag). Reaching out to the other vendors in that case should be easy. >>> 2. ecosystem- and hardware-specific APIs that are not standard or of >>> interest to the broader web at that time (or ever) may be shipped in >>> a way to limit their harm of the broader web (ex. only on a device >>> or only in specific builds with clear disclaimers about applicability >>> of exposed APIs). An example of this is the FM Radio API for Firefox >>> OS. >> >> When I read this, I read "It is okay to have Mozilla ship a phone with >> proprietary APIs". That means that we are okay with Mozilla creating the >> situation Apple created on Mobile, a situation that Mozilla has been >> criticising a lot. Shipping proprietary APIs on a specific device is >> harming the broader Web if that device happens to be one of the most >> used device out there... > > The way you read it obviously not something we want to do. What if we > dropped the "ecosystem-"? I can't see how we can allow ourselves to > ship hardware-specific APIs that don't work everywhere without an > exception like this. If this exception is only about mobile or hardware-specific APIs, we might want as well remove it. If we do not standardise things like FM Radio API it is not really because it requires a FM Radio (a lot of phones have this feature) but mostly because no one else want this for the moment. > Are there situations where we would ship such an > API on desktop if there's very little chance of the required hardware > existing there? Indeed, we would not ship an API on desktop if it doesn't work on desktop but I am not following the logic here. If an API works only on Mobile, it should be standardised as well. An good example being the Screen Orientation API. >>> Declaring Intent >>> API review >>> Implementation >>> Shipping >> >> I think some clarifications are needed in those areas. > > I changed the section headers to: > > Declaring Intent to Implement > API review > Implementation > Intent to Ship and Shipping > > How's that? I didn't meant the names but the content of those sections ;) >> The issue with having "dev-platform" finding a consensus with intent >> emails is that we might end up in a infinite debate. In that case, we >> should use the module system and have the module owner(s) of the >> associated area of code make the decision. If the module owner(s) can't >> take this decision, we could go upward and ask Brendan to make it. > > I admit I didn't think much about "dev-platform" coming to a consensus. > I guess I'd like major disputes to be handled on a case-by-case basis > and not have to define what should be done in the infinite discussion > situations. Maybe we should just be more forthcoming as reviewers or > module owners about something we wouldn't want to ship and thus save > potential implementors' time. I would bet that consensus is going to be reached most of the time. We used to discuss a lot of things in dev-webapi and we never ended up in infinite discussions. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
On 26/06/13 18:27, Ehsan Akhgari wrote: 2. ecosystem- and hardware-specific APIs that are not standard or of interest to the broader web at that time (or ever) may be shipped in a way to limit their harm of the broader web (ex. only on a device or only in specific builds with clear disclaimers about applicability of exposed APIs). An example of this is the FM Radio API for Firefox OS. >>> >>> When I read this, I read "It is okay to have Mozilla ship a phone with >>> proprietary APIs". That means that we are okay with Mozilla creating the >>> situation Apple created on Mobile, a situation that Mozilla has been >>> criticising a lot. Shipping proprietary APIs on a specific device is >>> harming the broader Web if that device happens to be one of the most >>> used device out there... >> >> The way you read it obviously not something we want to do. What if we >> dropped the "ecosystem-"? I can't see how we can allow ourselves to >> ship hardware-specific APIs that don't work everywhere without an >> exception like this. Are there situations where we would ship such an >> API on desktop if there's very little chance of the required hardware >> existing there? > > I think what Mounir is worrying about is the reverse situation where > people code against our APIs without knowing that they're not available > on other devices. Mounir, do you have the same concern about certified > Firefox OS APIs? What about privileged APIs? No, Certified-only, Privileged-only APIs are not exposed to the Web so I am fine with them not being actively standardised as long as we are not planning to increase their outreach (ultimately all those APIs should be exposed to the Web). However, I disagree with the idea that if an API is exposed to a small enough portion of the Web, it is fine to not worry about standardisation - because, anyway, it is just a small portion of the Web. This is what I understand from that exception and I think it is wrong. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 11/07/13 16:43, Neil wrote: > Milan Sreckovic wrote: > >> That last thing was another item I found useful in the previous life. >> When requesting a review from somebody, people could see "this person >> currently has X items in their review queue". >> > Even better would be if Bugzilla could compute their median review > turnaround for you. Those two metrics are pretty bad because they will move most review requests to a set of reviewers that have a fast turnaround. I'm not sure that is a good idea even though experienced developers tend to already know who are the fast reviewers. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On 26/07/13 18:29, Ehsan Akhgari wrote: > We're planning to implement a prototype of the NavigationController > interface (see bug 898524). We will try to get feedback from web > developers on the prototype and will use that feedback to change the spec > and the implementation and iterate on the API. Our major goal for now is > coming up with a good API that is useful for the intended use cases. Once > we're there, we will talk about plans to ship the API. For now, all of > this work will be disabled for web content. > > Please let me know if you have any questions! My understanding is that we wanted to implement this feature on top of Event Pages. Is there any plan to implement this too? -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: navigator.languages and languagechange
Hi dev-platform, As of today, I intend to land patches to implement navigator.languages and the languagechange event (on the Window object). This feature will not live behind a flag given that it is not complex nor controversial. Bug : https://bugzilla.mozilla.org/show_bug.cgi?id=889335 Spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#language-preferences Thanks, -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: upcoming Vibration API behaviour change in Firefox 32
Hi, Note: this is not an Intent to Ship because it is a minor change but given that it is still a content visible change, I want to make sure dev-platform is aware of it. I've landed a patch last week to update the vibration API implementation to match the current specification. The changes make vibrate() less pedantic and instead of failing if the array is too long or an element of the array is too large, it will truncate the input and continue. The rationale being that those limitations (array size and array element value) are platform specifics and a failure would just give a hint to the developer that she/he should try with a lower value. The compatibility risk is very low and it is very unlikely that any content out there depend on the current behaviour. The new behaviour should be shipping in Firefox 32. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Ship: navigator.doNotTrack returns { "0", "1", "unspecified" }
Hi, In Firefox 32, instead of returning "yes" or "unspecified", navigator.doNotTrack will start returning "1", "0" or "unspecified", making it closer to the specification in some aspects - returning "1" and "0" is what the specification requires, not "yes". It will also fix a nasty bug where asking to be tracked would be exposed as navigator.doNotTrack == "yes". There is compatibility risk in using "1" instead of "yes" but the specification requires "1" and other implementations matches. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On Sat, 6 Sep 2014, at 14:49, Martin Thomson wrote: > One idea that has been floated > (https://bugzilla.mozilla.org/show_bug.cgi?id=1002676) is to restrict > persistent permissions to secure origins. The reasoning there being that > a persistent grant can be trivially intercepted if you work in the clear. > That's a real security concern. One that gUM requires. That sounds interesting. I guess in this case you would want to mark the permission as session-specific with an expire time of a few hours? If there is a way to know whether a nsIPrincipal is associated with an authenticated origin, it should be fairly simple to implement inside nsPermissionManager. Though, it might require some UI, wouldn't it? -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On Sun, 7 Sep 2014, at 04:56, Martin Thomson wrote: > It's more the case that a persistent positive grant from permission > manager would be ignored for non-secure origins and non-secure origins > would not show any option to persist. I don't know the specifics about the UI, but you don't want to have a prompt showing up every time a call to an API is being made. It would be terribly frustrating for users and developers. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tips for standardizing web APIs
On Tue, 9 Sep 2014, at 00:15, Lars Knudsen wrote: > looks good, > > maybe adding to always take a holistic view on what you are doing and how > it will interact with other specs/standards used in the same apps (e.g. > considering DeviceOrientation and DeviceMotion before makeing > OrientationLock ;)) I am pretty sure we did. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On Tue, 9 Sep 2014, at 10:10, Daniel Veditz wrote: > On 9/8/2014 2:16 AM, Mounir Lamouri wrote: > > On Sun, 7 Sep 2014, at 04:56, Martin Thomson wrote: > >> It's more the case that a persistent positive grant from permission > >> manager would be ignored for non-secure origins and non-secure origins > >> would not show any option to persist. > > > > I don't know the specifics about the UI, but you don't want to have a > > prompt showing up every time a call to an API is being made. It would be > > terribly frustrating for users and developers. > > It wouldn't be every API call, it'd be the first API call. Would it help > to have an option to remember for the session (rather than > per-document)? We have no guarantee that the foo.com you connect to > tomorrow is the same foo.com you trusted today, especially if you're > connecting to a new network (e.g. coffee shop, airport, hotel). That's why I suggested a combination of time-based permission and session-based. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Touchpad event
On Thu, 11 Sep 2014, at 18:26, Ms2ger wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/11/2014 08:18 AM, Kershaw Chang wrote: > > First of all, you neglected to explain the standardization situation > here. Is this feature being standardized? If not, why not? How do > other browser vendors feel about it? Where does this stand in the current Touch Events vs Pointer Events situation, is the intent to re-use of those or create yet another standard? -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: BroadcastChannel API
On Thu, 25 Sep 2014, at 02:49, Jonas Sicking wrote: > Yes! > > Though as previously expressed, I don't think we should ship this until > it > supports sending Blobs. What do other UAs implement? -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: BroadcastChannel API
On Wed, 1 Oct 2014, at 10:51, Jonas Sicking wrote:
> On Tue, Sep 30, 2014 at 3:54 AM, Mounir Lamouri
> wrote:
> > On Thu, 25 Sep 2014, at 02:49, Jonas Sicking wrote:
> >> Yes!
> >>
> >> Though as previously expressed, I don't think we should ship this until
> >> it
> >> supports sending Blobs.
> >
> > What do other UAs implement?
>
> I don't know. Does anyone else implement BroadcastChannel yet?
It seems an information that would be worth adding to Intent to
{Implement,Ship}. It's clearly valuable because there is a big
difference in being the last to implement something and the first. Also,
not following exactly the specification would have a different impact in
both cases.
-- Mounir
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.origin
On Tue, 2 Dec 2014, at 02:09, Boris Zbarsky wrote: > Summary: document.origin returns the Unicode serialization of the > document's origin. The returned value does not depend on what > document.domain was set to. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=931884 > > Spec: http://dom.spec.whatwg.org/#dom-document-origin > > Platform coverage: All of them. > > Estimated release: 37 > > I don't plan to put this behind a pref. It's trivial to back out if > need be. > > Blink is considering implementing this too, and they're trying to find > out whether we plan to implement. I think this is a useful feature and > we should add it. For those interested. Blink patch: https://codereview.chromium.org/758913002 ... and blink-dev discussion: https://groups.google.com/a/chromium.org/d/msg/blink-dev/8aDWaY9b3BM/sb77MikxNncJ -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The current state of Talos benchmarks
On 08/31/2012 12:33 AM, Rafael Ávila de Espíndola wrote: > I was recently hit by most of the shortcomings you mentioned while > trying to upgrade clang. Fortunately, I found the issue on try, but I > will admit that comparing talos on try is something I only do when I > expect a problem. I'm a bit late into the game here but I would like to mention that I've never been able to use correctly talos on try. The few times one of my patches were suspected to regress, I sent them to try and every time the results were useless. The delta between min and max from different runs was so huge that I could have been able to use those results to say that my patches were actually improving performances as much as I could have say they were reducing them. As a result, my process has always been to pretend to use try, re-land my patch and hope it was actually not guilty. So far, I never had to try to fix a patch actually regressing something. Anyway, I don't think an indicator like talos is really useful if it's not reliable at all on try and locally. At the end of the day, you might easily end up doing like Justin who had to push a startup regression or simply forget about your patch (depending on the cost/benefit). In my opinion, trying to make talos reliable on try should be the first step if we want developers to care mare about those tests. Cheers, -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Imminent conversion of nsresult into an enum
On 09/21/2012 11:50 PM, Ehsan Akhgari wrote: > On 12-09-20 8:22 PM, Ehsan Akhgari wrote: >> Aryeh has been doing a heroic job (I mean, heroic, for reals!) in bug >> 777292 to make nsresult a C++ enum, as opposed to just an unsigned int. >> I've stepped in to help for the last few bits, and I'm planning to >> land this work as soon as the (hopefully) final patch that I put up for >> review gets an r+. This should generally not affect you, except that it >> makes the code better, but please keep an eye on any possible >> regressions, especially if you see negative nsresult values anywhere on >> Windows when this lands. > > I landed this on mozilla-central and mozilla-inbound a few hours ago, > and it seems to have stuck! If you're maintaining a project branch, > please make sure to merge m-c into your branch and test to make sure > your code is not doing anything bad with nsresults. If you see > problems, please ping me on IRC. Awesome! This already caught a stupid mistake I was writing (NS_ENSURE_SUCCESS instead of NS_ENSURE_TRUE). Kudos to both of you guys! -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: try: -p all considered harmful?
On 09/29/2012 06:40 PM, Gavin Sharp wrote: > On Sat, Sep 29, 2012 at 7:53 AM, Chris AtLee wrote: >> http://people.mozilla.org/~catlee/highscores/highscores.html is a report of >> where our time on Try is going. > > I think we should have this data feed into a cronjob that emails the > top ~5 weekly (ab)users of try, notifies them of their impact, and > suggests ways the can help avoid using these resources unnecessarily. I disagree with that. You can easily be in the top pushers on try for valid reasons the same way as you could very rarely use try for invalid reasons. Saying that using try extensively means you are abusing it is a wrong assumption IMO. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Not shipping prefixed APIs on the release channel
On 06/11/12 13:31, Henri Sivonen wrote: > Therefore, I propose that we adopt the following policy: > 1) APIs that are not ready for use by Web developers shall not be > shipped on the release channel (unless preffed off). For that, we will need some tools to know if we are building for Release (and let say Beta) where the feature should be hidden by default, with opposition to Aurora, Nightly or custom builds where the feature should be enabled by default. Also, how would that work for things that doesn't have Nightly/Aurora/Beta/Release channels? IMO, this is currently the main reason why prefixing is a pain: we want to allow devs to try the feature easily and Nightly/Aurora is there for that but having to disable the feature as soon as it reaches Beta is just too much maintenance. Cheers, -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Not shipping prefixed APIs on the release channel
On 14/11/12 19:27, Gavin Sharp wrote: > On Wed, Nov 14, 2012 at 10:53 AM, Mounir Lamouri wrote: >> For that, we will need some tools to know if we are building for Release >> (and let say Beta) where the feature should be hidden by default, with >> opposition to Aurora, Nightly or custom builds where the feature should >> be enabled by default. > > We already have ways of doing that (usually based off of > MOZ_UPDATE_CHANNEL). We could introduce some more elegant/robust > solution - we already do it enough that a better solution would > probably be nice. See > https://bugzilla.mozilla.org/show_bug.cgi?id=803276#c4. MOZ_UPDATE_CHANNEL contains a string and AFAIK, we can't use C preprocessor to compare strings so it might not be enough. >> Also, how would that work for things that doesn't have >> Nightly/Aurora/Beta/Release channels? > > What do you mean? I was thinking of things like Firefox OS that might not have such concept. We should make sure that they do not end up doing the wrong thing. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of MOZ_MAKE_FLAGS Considered Unnecessary
On 27/11/12 22:35, Gregory Szorc wrote: > I feel the build system should be as fast as possible by default - no > user action necessary. If you find that -j == # cores isn't providing > the fastest builds possible, please present your data and we'll change > the default value. I recently changed my laptop so I tried to tweak a bit my -j value and it happens that 2N is faster than N for me. IIRC, that was a 5-10 minutes difference for a 30-35 minutes basis. My feeling is that most of the time, the -j value isn't an exact science. During years, I was setting j to N+1, some people use N and other 2N. I would guess that the correct value depends on a lot of variables. If you really want to get rid of MOZ_MAKE_FLAGS, maybe you could add a new variable to just set the -j value with a default to N if most people thing this is the best value. Cheers, -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PHP to AngularJS - Permission Denied to access property
On 23/01/13 20:39, edgar.am...@gmail.com wrote: [...] > also, the the angularJS app is in my localhost port 81, the php file is in my > localhost, different port. You are very likely being stopped by a cross-origin check. Try to run both code within the same origin [1] and see if that works. [1] That means, same protocol, domain and port. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
