Re: PSA: Removing the Pointerlock permission UI

Awesome! Do we have a restriction that pointerlock can only be entered during a user action, like a click? And do we completely forgo the warning when the webpage is already in fullscreen mode? / Jonas On Thu, Jun 23, 2016 at 2:47 AM, Dale Harvey wrote: > In

Re: Redesigning the docshell/loadgroup/document interaction

On Fri, May 20, 2016 at 12:28 PM, Ben Kelly <bke...@mozilla.com> wrote: > On Fri, May 20, 2016 at 3:12 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> On Fri, May 20, 2016 at 8:04 AM, Ben Kelly <bke...@mozilla.com> wrote: >> > On Fri, May 20, 2016 at

Re: Redesigning the docshell/loadgroup/document interaction

On Fri, May 20, 2016 at 8:04 AM, Ben Kelly wrote: > On Fri, May 20, 2016 at 10:56 AM, Boris Zbarsky wrote: > >> Thoughts? Any obvious problems with this plan? > > We have the concept of network requests made from workers not associated > with a single

Re: Intent to deprecate: getUserMedia(cam+mic) to become all-or-nothing

On Thu, May 12, 2016 at 12:48 PM, Jan-Ivar Bruaroey wrote: > Our original intent behind those choices was to let users join a video > conference as an "audio only" participant. Unfortunately, sites don't expect > this behavior and often don't work right when the track is

Re: Intent to Use Counter: Everything

On Tue, May 10, 2016 at 1:31 PM, Mike Taylor wrote: > On 5/10/16 3:05 PM, Jack Moffitt wrote: > >> We have the Chrome popularity data, and we have the Edge team's data >> which covers the CSS spectrum quite well. I think it would be far more >> useful to start covering the DOM

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

On Mon, Apr 25, 2016 at 11:17 PM, Martin Thomson wrote: > On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan wrote: >> Could we probably restrict it to non-release builds (aurora and nightly) >> rather than restrict them to debug builds only? Debug builds are

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

I have two concerns with this. First off, it means that users might need to actively log in to websites more often. This is a really big hassle for users, especially on mobile. We did some studies when we did FirefoxOS between the differences between native versions and web version of various

Re: Intent to Ship: HTML5 and tags

On Thu, Apr 14, 2016 at 12:53 AM, Ting-Yu Lin wrote: > One major concern in the "intent to implement" discussion is the ability to > style the summary disclosure triangle. Currently summary has default style > "display: list-item", so we can style the triangle via the pseudo

Re: Coding style for C++ enums

On Fri, Apr 8, 2016 at 2:03 PM, Jeff Gilbert wrote: > Strong preference against eFoo, here. :) Would you mind saying why? / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Testing Wanted: APZ Scrollbar dragging

Hi Benoit, There's two problems that I've seen related to scrolling, and so possibly the result of APZ. The most obvious one is that if the child process is busy doing things, then the scrollable area seems "sticky". When you start scrolling there's a noticeable delay before the page starts

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

Re: Are we in favour of implementing the client hints header?

I filed https://github.com/httpwg/http-extensions/issues/155 https://github.com/httpwg/http-extensions/issues/156 / Jonas On Thu, Mar 10, 2016 at 3:07 PM, wrote: > Hey Jonas, > > Please feel free to raise issues: > https://github.com/httpwg/http-extensions/labels/client-hints

Re: Proposed W3C Charter: TV Control Working Group

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 >

Re: now available on desktop Firefox

On Mon, Mar 7, 2016 at 10:35 PM, Tim Guan-tin Chien wrote: > I am confused. In your proposal, are you referring to the chrome > *user/embedder* of (e.g. shell.html), or a chrome > *embedded* page (I am not aware of any example). What I'm saying is that in pages that run

Re: Are we in favour of implementing the client hints header?

I think the idea is a good one in general, though it would be good to get data from Google on how it's been used in practice. It's been quite a while since I reviewed the spec, so my thoughts below might be outdated (or I might be misremembering). There were two things that I found unfortunate

Re: now available on desktop Firefox

On Mon, Mar 7, 2016 at 9:51 PM, Tim Guan-tin Chien wrote: > This implies the Gaia System app, which is framed by shell.html (a > chrome document), will switch cookie jar when the default is changed, > no? No, the Gaia System app doesn't run as chrome (i.e. doesn't have a

Re: now available on desktop Firefox

On Mon, Mar 7, 2016 at 1:55 PM, J. Ryan Stinnett wrote: > By default, can't access the storage used by > for cookies and other site data, making it hard to share page > state across the two browser frame types. An additional feature mozbrowser noisolation> has been added,

Re: APNG and Accept-Encoding

On Sun, Feb 28, 2016 at 7:49 PM, Mike Lawther <mikelawt...@chromium.org> wrote: > On Wed, Feb 24, 2016 at 6:56 AM Jonas Sicking <jo...@sicking.cc> wrote: >> >> On Tue, Feb 23, 2016 at 6:14 AM, Anne van Kesteren <ann...@annevk.nl> >> wrote: >> >

Re: APNG and Accept-Encoding

On Tue, Feb 23, 2016 at 6:14 AM, Anne van Kesteren wrote: > On Tue, Feb 23, 2016 at 12:37 AM, Mike Lawther > wrote: >> I'm testing the water here :) Is this at all likely to fly? > > I think the problem with APNG, as opposed to other image formats, >

Re: Proposal to stop revving UUIDs when changing XPIDL interfaces

On Fri, Jan 15, 2016 at 11:41 AM, Joshua Cranmer  wrote: > On 1/15/2016 1:21 PM, Bobby Holley wrote: >> >> Has anyone measured recently whether there's still a significant perf win >> to making IIDs 32-bit? If we stop using them as a versioning tool, we >> could >>

Re: Intent to implement and ship: WebKitCSSMatrix

Ship it! On Thu, Jan 14, 2016 at 2:06 PM, William Chen wrote: > *Summary*: WebKitCSSMatrix has been available for years in WebKit based > browsers and has seen widespread usage on the web. This feature is > currently available in Chrome, Safari and Edge. Mike Taylor has been >

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

Hi Lars, So if I understand correctly, this will still remain disabled by default on all branches. However it will now be possible to test out on all branches by flipping a pref? If so that sounds great to me. / Jonas On Thu, Jan 14, 2016 at 5:16 AM, Lars Hansen wrote: >

Re: Feedback needed on proposal to add a web primitive for queuing microtasks

Sounds good to me as well. As long as it's very clearly defined that this doesn't return to the event loop and so UI events, timers, network events, etc MUST NOT be processed between the tasks under any circumstances. I.e. something like: function spinner() { window.enqueueMicrotask(spinner) }

Re: Improving blame in Mercurial

On Tue, Jan 5, 2016 at 9:57 AM, smaug wrote: >> I really liked a lot about the blame implementation that bonsai had, >> unfortunately we don't have a running copy any more AFAIK so it's hard to >> take a >> look at it. >> >> For one thing instead of showing author and changeset

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Mon, Jan 4, 2016 at 5:46 PM, Robert O'Callahan wrote: > On Tue, Jan 5, 2016 at 2:38 PM, Jeff Gilbert wrote: > >> > Essentially, we would extend the same API but allow the WDTStream >> >> interface to apply to more HTML elements, not just

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Mon, Jan 4, 2016 at 4:54 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Tue, Jan 5, 2016 at 1:18 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> A big problem is sticking HTML/CSS content into WebGL is that WebGL >> effectively enables reading

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

Yay! (I agree that it's sad that we need to do this, but still "yay" for being more compatible with the web). / Jonas On Wed, Dec 30, 2015 at 10:40 PM, Daniel Holbert wrote: > Summary: > A good chunk of the web today (and particularly the mobile web) > effectively

Re: WebUSB

On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan wrote: > 1) What I suggested: Whitelist vendor origins for access to their devices > and have vendor-hosted pages ("Web drivers"?) expose "safe" API to > third-party applications. > 2) Design a permissions API that one way or

Re: Intent to ship: referrerpolicy attribute

I think our implementation still has the problem that specifying referrerpolicy="none-when-downgrade" on an element has no effect. This is because the ReferrerPolicy enum uses the same value for RP_Unset, RP_Default and RP_No_Referrer_When_Downgrade. In general, that enum is a mess :( Would be

Re: Intent to implement and ship: FIDO U2F API

Any chance that the API can be made a little more JS friendly? First thing that stands out is the use of success/error callbacks rather than the use of Promises. Also the use of numeric codes, rather than string values, is a pattern that the web has generally moved away from. / Jonas On Tue,

Re: Intent to implement and ship: FIDO U2F API

eat for the W3C group and the successor API. I've got a > similar list started related to crypto and future-proofing. > > > On Tue, Dec 1, 2015 at 8:29 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> Any chance that the API can be made a little more JS friendly? First &

Re: Intent to unship: ISO-2022-JP-2 support in the ISO-2022-JP decoder

On Mon, Nov 30, 2015 at 7:38 AM, Henri Sivonen wrote: > Other browsers don't support this extension, so it clearly can't be a > requirement for the Web Platform Generally speaking, I don't think this reasoning is entirely accurate. We know that there's lots of

Re: Dan Stillman's concerns about Extension Signing

On Sat, Nov 28, 2015 at 5:28 PM, Mike Hoye wrote: > One key claim Stillman made, that " A system that takes five minutes to > circumvent does not “raise the bar” in any real way", is perhaps true in an > academic sense, but not in a practical one. We know a lot more than we

Re: Intent to implement and ship: Performance.translateTime

On Thu, Nov 19, 2015 at 5:38 PM, Boris Zbarsky wrote: >> Though Service Workers do actually have a 'client' object which >> represent window objects. So we could enable passing those as global >> to the translate function. > > That's a good idea. Want to raise it with the

Re: Intent to Implement: HTML and tags

I'll give the same feedback here as I did for . I don't think authors will use this very much unless they can style it. In this case enabling styling might not actually be that hard either, so especially worth looking into. / Jonas On Thu, Nov 19, 2015 at 1:21 AM, Ting-Yu Lin

Re: Intent to Implement: HTML and tags

On Thu, Nov 19, 2015 at 3:05 PM, Xidorn Quan <quanxunz...@gmail.com> wrote: > On Fri, Nov 20, 2015 at 6:22 AM, Jonas Sicking <jo...@sicking.cc> wrote: >> I'll give the same feedback here as I did for . >> >> I don't think authors will use this very much unless

Re: Intent to implement and ship: Performance.translateTime

On Thu, Nov 19, 2015 at 2:48 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 11/19/15 5:39 PM, Jonas Sicking wrote: >> >> This API doesn't seem to work for nested workers (which Blink doesn't >> implement), does it? Since there's no way in the window to get hold of

Re: Date, time, week, month and datetime attributes in the in Firefox

On Sun, Nov 1, 2015 at 3:06 PM, Xidorn Quan <quanxunz...@gmail.com> wrote: > On Fri, Oct 30, 2015 at 6:57 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> On Fri, Oct 30, 2015 at 12:36 AM, Xidorn Quan <quanxunz...@gmail.com> wrote: >>> Authors sometimes just want

Re: Date, time, week, month and datetime attributes in the in Firefox

On Fri, Oct 30, 2015 at 12:36 AM, Xidorn Quan wrote: > Authors sometimes just want something usable. It doesn't matter if it > is not stylable, or it doesn't fit in the UI. When they really need to > start caring about such things, they can switch to use jQuery UI then. I

Re: Date, time, week, month and datetime attributes in the in Firefox

On Thu, Oct 29, 2015 at 9:38 PM, Xidorn Quan wrote: > On Fri, Oct 30, 2015 at 10:25 AM, Ehsan Akhgari > wrote: >> On 2015-10-29 7:21 PM, Carlos Valim Coragem wrote: >>> >>> It seems that this problem only happens in the desktop version and not

Re: Merge moved to Thursday 29th

Please make sure to coordinate with the FirefoxOS release team since Gecko 44 is the release that will be used for FirefoxOS 2.5. / Jonas On Wed, Oct 28, 2015 at 1:10 PM, Sylvestre Ledru wrote: > Hello, > > Because we want to synchronize the release of 42 and 44

Re: Merging comm-central into mozilla-central

On Mon, Oct 26, 2015 at 8:27 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > On Tue, Oct 27, 2015 at 10:26 AM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> The question is, do we fix that friction by making collaboration >> easier, or do we fix it b

Re: Merging comm-central into mozilla-central

On Mon, Oct 26, 2015 at 3:45 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > On Mon, Oct 26, 2015 at 11:39 AM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> Given that people are already feeling pressure to fix up thunderbird >> code when they land patc

Re: Merging comm-central into mozilla-central

On Mon, Oct 26, 2015 at 9:20 AM, Robert Kaiser <ka...@kairo.at> wrote: > Jonas Sicking schrieb: >> >> I definitely think that some aspects of Firefox development has gotten >> easier thanks to the split. > > I'd like to see which. I don't see much that has gotten e

Re: Merging comm-central into mozilla-central

On Fri, Oct 23, 2015 at 4:30 PM, Gregory Szorc wrote: > If we (m-c build peers) didn't care about comm-central at all, I can pretty > much guarantee that comm-central would be perpetually broken once m-c build > system improvements ramp up in the months ahead. C-c's contributors

Re: Merging comm-central into mozilla-central

On Fri, Oct 23, 2015 at 3:53 PM, Joshua Cranmer  wrote: >> The goal of putting seamonkey and thunderbird in separate trees has >> always been to make firefox development easier, not harder. That >> should include the build system. > > And the point of this thread is that it

Re: Merging comm-central into mozilla-central

On Fri, Oct 23, 2015 at 3:11 PM, Gregory Szorc wrote: > > We'll be investing pretty heavily in the Firefox build system in 2016. I > cannot stress enough the pain comm-central's existence as a separate > repository gives us when trying to make build system, mach, and automation

Re: Intent to implement and ship: window.orientation and orientationchange event

On Tue, Oct 20, 2015 at 2:49 AM, Mounir Lamouri wrote: > Should we add this to the Screen Orientation specification? I think so yes. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to implement and ship: window.orientation and orientationchange event

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

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 4:14 PM, Nicholas Nethercote wrote: > >> not more ways for the user to tell the build system "only rebuild some >> stuff". > > ... except that bholley and ehsan are asking for a way to override the > dependency tracking and just rebuild particular

Re: Please do not use the Date type in Web IDL APIs

On Fri, Oct 16, 2015 at 11:44 AM, Boris Zbarsky wrote: > So if you want to have value type like behavior, use a value type; for now > long long (in IDL terms; Number in JS terms) is good FWIW, when the problems with using Date objects in attributes were raised with TC39, their

Re: Allowing web apps to delay layout/rendering on startup

On Sat, Oct 10, 2015 at 9:26 PM, wrote: > On Saturday, October 10, 2015 at 4:28:30 AM UTC-7, Mounir Lamouri wrote: >> 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

Re: Please do not use the Date type in Web IDL APIs

On Fri, Oct 16, 2015 at 9:20 AM, Martin Thomson wrote: > On Fri, Oct 16, 2015 at 6:39 AM, Boris Zbarsky wrote: >> You should _especially_ not create attributes of type Date. > > > Well, that's interesting. I think that I might have to eat crow: >

Re: Decommissioning "dumbmake"

> |mach build binaries| is much slower for me than the present behavior, > because I often hack on header files that are included all over the tree, > but whose #include-ers generally don't need to be rebuilt all of the time. Before we had mach, I had an alias for linking libxul. If there is a

Re: Intent to ship: IDB getAll/getAllKeys/openKeyCursor

Yay! Ship it! On Wed, Oct 14, 2015 at 10:40 AM, Kyle Huey wrote: > I intend to ship the following features in Gecko 44: > > IDBObjectStore.getAll > IDBObjectStore.getAllKeys > IDBObjectStore.openKeyCursor > IDBIndex.getAll > IDBIndex.getAllKeys > > These features will be

Re: Read only non-privileges access to mozSettings (old navigator.mozHour12 in platform)

It's pretty easy to enable access to specific settings in mozSettings to lower privileged content these days. If it is acceptable that the pages have to be part of an installed app (hosted or packaged), then all it takes is adding a few entries to PermissionsTable.jsm / Jonas On Tue, Oct 13,

Re: Disabling C++ tests by default?

On Fri, Oct 2, 2015 at 1:03 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > On 2015-10-02 2:42 PM, Jonas Sicking wrote: >> >> It might still mean that we can save time on tryserver if we only >> build these by default if the user has opted in to running the >&

Re: Disabling C++ tests by default?

It might still mean that we can save time on tryserver if we only build these by default if the user has opted in to running the relevant tests. I agree with Gregory. I really don't see much value in building these binaries by default. For the people that use them often enough that they are worth

Re: NPAPI plug-in use case: live video broadcast

On Sep 26, 2015 09:33, "Eric Rescorla" wrote: > > On Fri, Sep 25, 2015 at 3:20 PM, wrote: > > > On Saturday, September 19, 2015 at 8:15:50 PM UTC+2, Eric Rescorla wrote: > > > On Sat, Sep 19, 2015 at 11:09 AM, Oliver Lietz wrote: > > > > > >

Re: Intent to ship: Directory picking and directory drag-and-drop

On Tue, Sep 22, 2015 at 11:16 PM, Eric Rescorla wrote: >> The api has been extensively discussed with all browser vendors and has >> changed substantially in response to this > > Can you please point me to those changes and to the security analysis? Security wasn't discussed much

Re: Intent to ship: Directory picking and directory drag-and-drop

On Sep 21, 2015 11:57, "Eric Rescorla" <e...@rtfm.com> wrote: > > On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> Note that this, similarly to clipboard integration, is already exposed >> to the web through flash. So

Re: Intent to ship: Directory picking and directory drag-and-drop

On Sep 21, 2015 11:57, "Eric Rescorla" <e...@rtfm.com> wrote: > > On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> Note that this, similarly to clipboard integration, is already exposed >> to the web through flash. So

Re: Intent to ship: Directory picking and directory drag-and-drop

Note that this, similarly to clipboard integration, is already exposed to the web through flash. So the main goal of this feature is to enable developers to migrate off of flash and instead use Gecko. That said, if there are ways we can improve the UI here to further explain to users what is

Re: Proposed W3C Charters: Web Platform and Timed Media Working Groups

On Thu, Sep 10, 2015 at 5:27 PM, Tantek Çelik <tan...@cs.stanford.edu> wrote: >> On 09/10/2015 06:36 PM, Jonas Sicking wrote: >> > If I am the only one that wants to put in a formal objection here, >> > then I'll let it go and go with whatever everyone else think we &

Re: Proposed W3C Charters: Web Platform and Timed Media Working Groups

If I am the only one that wants to put in a formal objection here, then I'll let it go and go with whatever everyone else think we should do. / Jonas On Wed, Sep 9, 2015 at 11:22 PM, L. David Baron <dba...@dbaron.org> wrote: > On Tuesday 2015-09-08 23:25 -0700, Jonas Sicking wrote:

Re: Proposed W3C Charters: Web Platform and Timed Media Working Groups

On Tue, Sep 8, 2015 at 5:33 PM, Tantek Çelik wrote: > On Wed, Aug 19, 2015 at 3:16 AM, Henri Sivonen wrote: >> On Sun, Aug 9, 2015 at 9:59 PM, L. David Baron wrote: >> > The W3C is proposing revised charters for: >> > >> > Web

Re: Proposal: revisit and implement navigator.hardwareConcurrency

I'm ok with implementing this. My biggest concern has always been fingerprinting, and I think that we'll need some way to deal with active (i.e. client-side) fingerprinting anyway, so I don't think this makes a big difference either way. / Jonas On Tue, Sep 8, 2015 at 12:21 PM, Luke Wagner

Re: Intent to Implement and Ship: Permissions API

On Mon, Aug 24, 2015 at 11:57 PM, 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

Re: Intent to Implement and Ship: Permissions API

I'm less psyched about Permissions.request, but looking forward to having .query ship! Does it also work in workers? / Jonas On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas birunt...@mohanathas.com wrote: Hi, navigator.permissions.query has been Nightly-only for a few weeks. We are

Re: Intent to Ship: Updated third-party iframe storage behavior

On Tue, Aug 18, 2015 at 2:39 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-08-18 5:37 PM, Tanvi Vyas wrote: It is nice to see that we are moving towards an Accept third party cookies and data setting instead of just Allow third party cookies. Will localstorage and sessionstorage

Re: Intent to Ship: Screen Orientation API

Yay! On Mon, Aug 17, 2015 at 1:55 PM, William Chen wc...@mozilla.com wrote: Summary: The Screen Orientation API provides the ability to read the screen orientation type and angle, to be informed when the screen orientation state changes, and be able to lock the screen orientation to a specific

Re: Proposed W3C Charters: Web Platform and Timed Media Working Groups

On Sun, Aug 9, 2015 at 11:59 AM, L. David Baron dba...@dbaron.org wrote: The W3C is proposing revised charters for: Web Platform Working Group: http://www.w3.org/2015/07/web-platform-wg.html https://lists.w3.org/Archives/Public/public-new-work/2015Jul/0020.html ... The Web Platform

Re: Web API equivalent of nsIEffectiveTLDService / publicsuffix.org database?

On Sun, Aug 9, 2015 at 2:51 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Aug 9, 2015 at 4:00 AM, Andrew Sutherland asutherl...@asutherland.org wrote: Are there any plans to surface the contents of

Re: Allowing web apps to delay layout/rendering on startup

On Thu, Aug 6, 2015 at 12:53 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Aug 4, 2015 at 9:10 PM, James Burke jbu...@mozilla.com wrote: If the meta tag, or whatever the toggle becomes, is set, then I expect if the page's JS asks for a DOM element's box properties, it will get values

Re: Allowing web apps to delay layout/rendering on startup

On Thu, Aug 6, 2015 at 1:07 AM, Anne van Kesteren ann...@annevk.nl wrote: A simple solution here would be to simply use MutationObservers to detect when the last meta is removed. Any time that layout properties are queried after that they could behave like they currently do, i.e. force a

Re: Fingerprinting of battery status?

Fingerprinting doesn't seem useful if the fingerprint changes every few minutes as the battery level changes. I do agree that there are concerns that if the user has private-browsing pages and non-private-browsing pages open at the same time, that the pages can track when exactly the battery

Re: Allowing web apps to delay layout/rendering on startup

On Tue, Aug 4, 2015 at 10:06 AM, Bobby Holley bobbyhol...@gmail.com wrote: How about a scheme in which there can be N such meta elements, and the painting only happens when all of them are gone (or some timeout occurs)? That solve the common case that Jonas is talking about, and allows

Re: Allowing web apps to delay layout/rendering on startup

On Tue, Aug 4, 2015 at 2:55 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Aug 4, 2015 at 11:07 AM, James Graham ja...@hoppipolla.co.uk wrote: I am extremely wary of designing a solution like this where there's a single master switch that any code can unilaterally flip; if the assumption

Re: Use of 'auto'

On Mon, Aug 3, 2015 at 5:06 PM, Karl Tomlinson mozn...@karlt.net wrote: but I don't see much advantage of public constructors over something like static already_AddRefedFoo Foo::Create() or static nsRefPtrFoo Foo::Make() Fair enough. Though it is somewhat more boilerplate in the class

Re: Use of 'auto'

On Mon, Aug 3, 2015 at 6:03 PM, Mike Hommey m...@glandium.org wrote: On Mon, Aug 03, 2015 at 05:55:01PM -0700, Jonas Sicking wrote: On Mon, Aug 3, 2015 at 5:06 PM, Karl Tomlinson mozn...@karlt.net wrote: but I don't see much advantage of public constructors over something like static

Re: Allowing web apps to delay layout/rendering on startup

On Sun, Aug 2, 2015 at 10:28 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Aug 3, 2015 at 4:53 PM, Jonas Sicking jo...@sicking.cc wrote: The need is not for an event, no? But rather for an API which allows the page to tell the browser that it's ready for initial rendering? Right

Re: Allowing web apps to delay layout/rendering on startup

On Mon, Aug 3, 2015 at 12:32 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Aug 3, 2015 at 9:23 AM, Jonas Sicking jo...@sicking.cc wrote: I think something like a meta name=do-not-render might be a simpler solution here. Coupled with either simply removing the meta from the DOM

Re: Allowing web apps to delay layout/rendering on startup

On Sun, Aug 2, 2015 at 11:12 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Aug 3, 2015 at 7:59 AM, Jonas Sicking jo...@sicking.cc wrote: Ah, yes, that makes sense. Is this yet another API where we want to basically have an internal list of promises? someInstance.doNotRenderUntil

Re: Allowing web apps to delay layout/rendering on startup

On Sun, Aug 2, 2015 at 2:41 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Aug 3, 2015 at 8:15 AM, Jonas Sicking jo...@sicking.cc wrote: Often times the chrome of a webapp is ready before various other things that are loaded during initial page load is loaded. OK then, I guess

Re: Allowing web apps to delay layout/rendering on startup

On Sun, Aug 2, 2015 at 2:03 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Sun, Aug 2, 2015 at 11:58 AM, Zibi Braniecki zbigniew.branie...@gmail.com wrote: So maybe we would need another event that the website fires to indicate when it for paint/cache/screenshot. Assuming pages have

Re: Allowing web apps to delay layout/rendering on startup

On Sat, Aug 1, 2015 at 12:30 PM, Zibi Braniecki zbigniew.branie...@gmail.com wrote: 2) We want to bring app to foreground/paint it only when the app's chrome is visually complete. I would very much want this. Right now, during a navigation from page A to page B I believe that we render A until

Re: Intent to implement: File system provider API

support. I suspect there will be more things to point to once the initial support has landed. / Jonas Best Regards, Shih-Chiang Chien Mozilla Taiwan On Mon, Jul 27, 2015 at 6:31 AM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Jul 25, 2015 at 7:14 AM, Kershaw Chang kech...@mozilla.com

Re: Intent to implement: File system provider API

On Mon, Jul 27, 2015 at 4:31 AM, Ted Mielczarek t...@mielczarek.org wrote: On Fri, Jul 24, 2015, at 12:43 PM, Jonas Sicking wrote: On Fri, Jul 24, 2015 at 3:49 AM, David Rajchenbach-Teller dtel...@mozilla.com wrote: On 24/07/15 11:38, Jonas Sicking wrote: I think we should allow addons

Re: Intent to implement: File system provider API

On Sat, Jul 25, 2015 at 7:14 AM, Kershaw Chang kech...@mozilla.com wrote: Since the addon model on Firefox OS is not implemented now, I still use the old term apps in previous mail. I also think it makes much more sense to make this API to be only available for addons. Great! In addition,

Re: Hash table iterators, and a call for help

On Thu, Jul 23, 2015 at 10:16 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I wonder if converting all the uses of PLHashTable into PLDHashTable would instead be a better approach. Yes please! Though IIRC they are have different performance characteristics, which might make that

Re: Intent to implement: File system provider API

I think we should allow addons to implement something like this. But I don't think it's something that we should let apps do. / Jonas On Fri, Jul 24, 2015 at 1:13 AM, Kershaw Chang kech...@mozilla.com wrote: Hi all, Summary: File system provider API [1] is now supported by Google. This API

Re: Hash table iterators, and a call for help

On Fri, Jul 24, 2015 at 1:59 AM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Fri, Jul 24, 2015 at 5:45 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 23, 2015 at 10:16 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I wonder if converting all the uses of PLHashTable

Re: Proposed W3C Charters: All Groups, XML Activity

On Fri, Jul 24, 2015 at 2:23 PM, L. David Baron dba...@dbaron.org wrote: # It's disappointing to see the W3C putting this much effort into XML work # that is not related to the needs of the Web. We don't support this # work, and would rather see the resources going into it going into things #

Re: Intent to implement: File system provider API

On Fri, Jul 24, 2015 at 3:49 AM, David Rajchenbach-Teller dtel...@mozilla.com wrote: On 24/07/15 11:38, Jonas Sicking wrote: I think we should allow addons to implement something like this. But I don't think it's something that we should let apps do. / Jonas So Dropbox, Cozy Cloud, etc

Re: Proposed W3C Charters: All Groups, XML Activity

On Thu, Jul 23, 2015 at 3:43 PM, L. David Baron dba...@dbaron.org wrote: I'm not sure it's really a fight I want to take on right now, though. Trying to kill things at W3C has generally not seemed worth the effort to me. It's better to ignore it and let it die out by itself due to lack of

Re: [WebAPI] New Proposal of IMS Registration Manager

On Wed, Jul 22, 2015 at 3:38 AM, Bevis Tseng bts...@mozilla.com wrote: To prevent exposing too much in the web api level unnecessarily, instead of creating new attribute in Navigator.webidl, we could define the ImsHandler as one attribute of MozMobileConnection and remove mozImsManager from

Re: [WebAPI] New Proposal of IMS Registration Manager

On Wed, Jul 22, 2015 at 1:57 AM, Martin Thomson m...@mozilla.com wrote: I think that building these sorts of features into the web platform at large is a very bad idea. I assume that this API is only going to be exposed to certified apps. Effectively that means that it's no more exposed to the

Re: Intent to implement HTMLMediaElement.srcObject partially

On Sun, Jul 19, 2015 at 2:45 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Jul 16, 2015 at 5:09 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jul 15, 2015 at 12:42 PM, Jan-Ivar Bruaroey j...@mozilla.com wrote: This means it will throw TypeError on set of: MediaSource objects

Re: Intent to implement HTMLMediaElement.srcObject partially

On Wed, Jul 15, 2015 at 12:42 PM, Jan-Ivar Bruaroey j...@mozilla.com wrote: This means it will throw TypeError on set of: MediaSource objects, Blob objects, and File objects, for now. For what it's worth, I think implementing Blob/File support would be quite trivial. Just make elem.srcObject =

Re: Intent to implement W3C Manifest for web application

On Tue, Jul 14, 2015 at 3:00 PM, mar...@marcosc.com wrote: Some of the things raised: * It's not clear what problems manifest solves: do we really want to replicate native app installation behavior on the Web? We don't have a good history of making this work in various products. *

  1   2   3   >