Re: Permission UI

[Gervase Markham]

On 05/03/15 07:40, Anne van Kesteren wrote:
> This would require everything that's like github.io to register as a
> public suffix. 

github.io already is a public suffix :-) If some private entity is
handing out subdomains to mutually-untrusting 3rd parties, there are a
number of reasons they should be in the PSL. If they aren't, they'll
have bigger problems than one site not being able to use localstorage
because another one has sucked it all up.

> And if someone actually wants to attack users I doubt
> the budget would only allow for a single domain. This is why I'm not
> really convinced this eTLD coupling is really of help.

Doesn't it also prevent accidental as well as deliberate problems? If
there was no eTLD coupling, one site that was doing something they
thought was perfectly reasonable could nevertheless exhaust the
available resources for everyone on a resource-constrained device.

Gerv

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

Update on Web Components

[Anne van Kesteren]

I thought it might be good to give a quick update. As announced
https://hacks.mozilla.org/2014/12/mozilla-and-web-components/ we're
not doing HTML imports. We have not found an internal need and
feedback from Ember, React, and peers in the standards community
suggest that iterating on JavaScript modules and new fetching
primitives is sufficient for now.

For custom elements and shadow DOM there's documents where we keep
track of outstanding issues:

* https://wiki.whatwg.org/wiki/Custom_Elements
* https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits

Unfortunately it does not look like agreement will be found soon. The
high-level bit of feedback that keeps coming back is that we need to
find a way to get layout fast and code more manageable. How exactly we
should get there is still unclear.

There will be a meeting
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0661.html
(April 24, Mountain View) to discuss shadow DOM in particular and
perhaps http://lanyrd.com/2015/extwebsummit/ (April 19, San Francisco)
can also be used as a discussion venue.

We have had some discussions around within Mozilla in Portland.
Perhaps we should have another one over Vidyo? Hearing from Gaia again
now v3 is underway would be useful. (Tentative suggestion: Thursday
March 12, 9AM PST.)


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

Re: Help needed: define Bugzilla components in moz.build files

[Andrew McCreight]

I hacked up a crude script to collate the results from Gregory's
spreadsheet that collates the results across a subdirectory into sort of
useful results:

https://github.com/amccreight/gecko-components

From the spreadsheet, do "download as" and then "comma separate values" to
get the input format.

For the dom/ subdirectory, it produces output like:

dom: Core :: DOM (2)
dom/phonenumberutils: Firefox OS :: Runtime (1), Firefox OS :: RIL (1),
Firefox :: Developer Tools (1), Core :: DOM: Device Interfaces (1)
dom/ipc: Core :: DOM: Content Processes (22), Core :: IPC (14), Core :: DOM
(10), Core :: DOM: IndexedDB (8)
dom/notification: Core :: DOM (7), Firefox OS :: Gaia::System (3)
dom/indexedDB: Core :: DOM: IndexedDB (45), Core :: DOM (15), Core :: XPCOM
(8), Core :: JavaScript Engine (2)
dom/tv: Firefox OS :: General (24)
dom/workers: Core :: DOM (27), Core :: DOM: Workers (26), Firefox ::
Developer Tools: Debugger (4), Core :: JavaScript Engine (4)
dom/cache: Core :: DOM (60)

There are a number of obvious improvements that could be made, like doing
some kind of coalescing (so if A, A/B, A/C, and A/D are in the same
component, but A/E isn't, then you'd want A and A/E to have components
indicated), and automatically inserting changes to a tree so you could make
a patch, but I'm not sure if it is worth the effort or not.  (I'm thinking
about this because dom/ has something like 90 subdirectories.)

Andrew

On Wed, Mar 4, 2015 at 9:48 PM, Gregory Szorc  wrote:

> I was accidentally sorting based on bug component name, not the count of
> bugs. The spreadsheet has been updated.
>
> Sorry for the confusion.
>
> On Wed, Mar 4, 2015 at 5:50 PM, Botond Ballo  wrote:
>
>> I see other wrongness in that spreadsheet, too. For example, for the
>> first file I cared to check, gfx/layers/apz/src/APZCTreeManager.cpp,
>> the spreadsheet gives "Firefox for Metro :: General" as the bug.
>> However, I just checked, and out of the 80 bugs that touched the file
>> since its creation, which was in 2014, 63 were in the "Core :: Panning
>> and Zooming" component, and only 1 was in "Firefox for Metro ::
>> General".
>>
>> Cheers,
>> Botond
>>
>> On Wed, Mar 4, 2015 at 4:57 PM, Cameron McCormack  wrote:
>> > L. David Baron:
>> >> Having looked at the data for layout/, I think the results in the
>> >> spreadsheet are mostly wrong, and I'd rather not populate things
>> >> using it.
>> >
>> > A lot of the wrongness is files which weren’t updated recently, except
>> > for tree-wide changes such as introducing nullptr, which got filed in
>> > components like Core :: XPCOM.
>> >
>> > --
>> > Cameron McCormack ≝ http://mcc.id.au/
>> > ___
>> > 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