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

[Anne van Kesteren]

On Fri, Oct 16, 2015 at 6:33 PM, Boris Zbarsky  wrote:
> On 10/16/15 12:23 PM, Jonas Sicking wrote:
>> Should we try to remove support for "Date" from our webidl implementation?
>
> I would love to do that, yet.  Getting there might be complicated.

We could maybe special case the existing usage and prevent new usage?


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

Changes to third-party access for Mozilla organizations on GitHub

[Doug Turner]

For security reasons, we will be making changes to third-party application 
access for Mozilla organizations on GitHub. This means that GitHub applications 
not run by Mozilla will have to go through a more formal approval process by 
Mozilla GitHub organization owners before they are added (not just anyone can 
enable third-party applications). This will help ensure third-party 
applications aren't inadvertently granted access to data in and privileges for 
Mozilla's GitHub organizations and projects that they shouldn't have.

When we activate the new security settings:

* Existing third-party applications may lose access to Mozilla GitHub 
organizations and projects therein. This has the potential to disrupt tools, 
processes, and workflows.
* SSH keys created before February 2014 will lose access. You will have to 
upload a new SSH key to speak with GitHub servers.
* Hooks from private projects will no longer be sent to unapproved applications.
* Other items listed at 
https://help.github.com/articles/about-third-party-application-restrictions/

There is no perfect time to perform this change. There will be some disruption. 
But since security is at stake, it needs to performed sooner rather than later.

We have scheduled the switch for 1700 UTC / 1000 PDT on Tuesday, October 20. 
Mozilla GitHub organization owners will be on call in #github and at 
github-own...@mozilla.org to approve any urgent requests for third-party 
application approval.

During this switch, the many popular applications such as Travis CI, Circle CI, 
ect. may experience temporary downtime.  We expect the downtime to be under 5 
minutes.

Thank you for your understanding.
Doug


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

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

[Martin Thomson]

WFM.  I'll see what I can do about fixing RTCCertificate.  I think
that the breakage should be minimal if I just change it.

On Fri, Oct 16, 2015 at 11:44 AM, Boris Zbarsky  wrote:
> On 10/16/15 2:00 PM, Martin Thomson wrote:
>>
>> On Fri, Oct 16, 2015 at 9:30 AM, Boris Zbarsky  wrote:
>>>
>>> I'm not sure what custom code you're talking about.  What exactly are you
>>> proposing?
>>
>>
>> Date is fundamentally just an integer when you get down to it.  Treat
>> it like one.  An integer value is copied when you return it, so
>> modifications don't affect the underlying structure.
>
>
> Integer values also do structural ==, not object identity ==.  And can't be
> mutated (mutating actually just creates a new value)
>
> You seem to be arguing that Date should really be a value type in ES. That's
> an argument I'm sympathetic to, but that's not the Date we have right now.
>
> 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.  If you want to have a
> possibly-shared reference to a mutable thing, then Date makes sense.  Once
> ES grows actual value types, we can think about doing something like that
> for date return values in APIs.
>
>
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Decommissioning "dumbmake"

[Gregory Szorc]

On Thu, Oct 15, 2015 at 6:37 PM, Nicholas Nethercote  wrote:

> On Fri, Oct 16, 2015 at 11:37 AM, Bobby Holley 
> wrote:
> >
> > |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.
>
> I used to have a bunch of my own aliases for building particular
> directories (and toolkit/library if necessary) and then relinking.
> (Sounds like maybe I partially reimplemented dumbmake myself? Not
> sure.) I stopped using them once |mach build binaries| came along
> because it was better for my use cases.
>
> I suspect the very small number of people who are in your position can
> do something similar?
>

This is pretty much how everyone did everything 3+ years ago: waiting
45-90s for a `make -f client.mk` to traverse all the tiers and directories
when a single C++/JS file changed was just wasteful. So lots of people
cobbled together shell aliases and scripts for patterns like `make -j8
services && make -j8 toolkit/components && make -j8 browser` or `make -j8
-C dom/base && make -j8 -C toolkit/library`. It was a good hack to gain
build/development speed while sacrificing a little build purity.

dumbmake was a formal establishment of these practices so that people
didn't have to know as many inner workings of the build system and code up
these aliases.

The "binaries" target came along after dumbmake and made the C++ build
procedure infinitely better. Now we have "fastermake," which is the rough
equivalent but for frontend and JavaScript developers. But as awesome as
these targets are, they can still build more than is desired (especially in
the edit .h file case). This slows down iteration cycles and slows down
developers.

For this reason, I think dumbmake needs to remain or be replaced by
something that allows Gecko developers to easily perform a partial (and
probably incorrect end state) build. I /think/ this could be as simple as a
"xul" target that linked libxul. This way, people could type `mach build
dom/base xul` and build all binaries (including static libraries) under a
source directory and link libxul.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Bobby Holley]

On Fri, Oct 16, 2015 at 9:55 AM, Boris Zbarsky  wrote:

> On 10/16/15 12:54 PM, Anne van Kesteren wrote:
>
>> We could maybe special case the existing usage and prevent new usage?
>>
>
> Yes.  Most simply by renaming it in our bindings to LegacyDateDoNotUse.  ;)
>
> But that involves reviewers catching new uses, hence this thread.


How about renaming it in our webidl to the same thing?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Virtual crash debugging team to fill in for David Major

[Vladan Djeric]

Hi all,

David Major is leaving Mozilla, so I've formed a virtual team composed of
other Mozilla devs with crash debugging skills to fill in for David while
we search for a new stability engineer.

If you need help analyzing top crashes, you can reach this virtual team at
crashde...@mozilla.com

A big thanks to Aaron Klotz, Andrew McCreight, Kyle Huey, Nathan Froyd and
Ted Mielczarek for agreeing to help out with crash debugging.

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

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

[Boris Zbarsky]

On 10/16/15 2:00 PM, Martin Thomson wrote:

On Fri, Oct 16, 2015 at 9:30 AM, Boris Zbarsky  wrote:

I'm not sure what custom code you're talking about.  What exactly are you
proposing?


Date is fundamentally just an integer when you get down to it.  Treat
it like one.  An integer value is copied when you return it, so
modifications don't affect the underlying structure.


Integer values also do structural ==, not object identity ==.  And can't 
be mutated (mutating actually just creates a new value)


You seem to be arguing that Date should really be a value type in ES. 
That's an argument I'm sympathetic to, but that's not the Date we have 
right now.


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.  If you want 
to have a possibly-shared reference to a mutable thing, then Date makes 
sense.  Once ES grows actual value types, we can think about doing 
something like that for date return values in APIs.


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

Re: Intent to unship: jar: URIs from content

[Boris Zbarsky]

On 10/16/15 1:13 PM, Gregory Szorc wrote:

On Thu, Oct 15, 2015 at 4:08 PM, Robert O'Callahan 
wrote:


I'm sad that I won't be able to use jar: URLs to load testcases in ZIP
files uploaded to Bugzilla, but this sounds like the right thing to do.



If this is a common use case, then `mach test` should be able to accept a
bz://123456 URL, autodiscover a test case attachment on that bug, download
it, and run it.


This would automate the "download, unzip" step, sure.

Note that this still changes the security context the attachment is 
running in.  I'm not super-happy running random reporter-provided code 
from file:// without having looked at it first.


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

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

[Boris Zbarsky]

On 10/16/15 12:54 PM, Anne van Kesteren wrote:

We could maybe special case the existing usage and prevent new usage?


Yes.  Most simply by renaming it in our bindings to LegacyDateDoNotUse.  ;)

But that involves reviewers catching new uses, hence this thread.

-Boris

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

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

[Martin Thomson]

On Fri, Oct 16, 2015 at 9:30 AM, Boris Zbarsky  wrote:
> I'm not sure what custom code you're talking about.  What exactly are you
> proposing?

Date is fundamentally just an integer when you get down to it.  Treat
it like one.  An integer value is copied when you return it, so
modifications don't affect the underlying structure.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

[Ehsan Akhgari]

On 2015-10-16 12:16 PM, Justin Dolske wrote:

On 10/16/15 7:20 AM, Ehsan Akhgari wrote:

On 2015-10-15 5:00 PM, Mike Conley wrote:

Note that this should not affect Gecko’s behaviour when the  is
displayed “inline” (for example, when the  has a “multiple”
attribute, or a “size” attribute with a value greater than 1). I'm only
concerned with the dropdown case.


Why should the behavior be different with non-drop-down select elements?


It makes sense to me because in the drop-down case, the user is
interacting with chrome UI (as opposed to something actually in
content).  Same thing with context menus, autocomplete dropdowns, etc.


That sounds like justifying a specific behavior to me.  Here is the 
counter argument:


The author has a  in their app.  They are relying on 
receiving the events on the option elements.  Then they add a 
mySel.removeAttribute("size") call and suddenly their event handlers 
stop working?!


That makes no sense to me!

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

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

[Mike Conley]

>> That makes no sense to me!

It might make no sense, but it's what Chromium has been shipping for (at
least) the last while. Not saying it's right, just saying that's where
it is.

I've updated my testcase[1] to demonstrate. There is now a click event
handler on the "Friday" , and the  defaults to showing
inline 's.

In Chrome, click Friday. Then toggle the "inline select" checkbox, and
then choose Friday from the dropdown. You'll only see the event handler
fire in the first case.

I guess this is what happens when the spec is unclear. :/

The easy path forward on bug 1090602 is to follow Chrome's approach. The
harder path is to try to maintain what we currently do (and fire events
with the dropdown and without).

So what should we do? Who makes the decision on this?

[1]: https://bug1090602.bmoattachments.org/attachment.cgi?id=8674977

On 2015-10-16 12:56 PM, Ehsan Akhgari wrote:
> On 2015-10-16 12:16 PM, Justin Dolske wrote:
>> On 10/16/15 7:20 AM, Ehsan Akhgari wrote:
>>> On 2015-10-15 5:00 PM, Mike Conley wrote:
 Note that this should not affect Gecko’s behaviour when the  is
 displayed “inline” (for example, when the  has a “multiple”
 attribute, or a “size” attribute with a value greater than 1). I'm only
 concerned with the dropdown case.
>>>
>>> Why should the behavior be different with non-drop-down select elements?
>>
>> It makes sense to me because in the drop-down case, the user is
>> interacting with chrome UI (as opposed to something actually in
>> content).  Same thing with context menus, autocomplete dropdowns, etc.
> 
> That sounds like justifying a specific behavior to me.  Here is the
> counter argument:
> 
> The author has a  in their app.  They are relying on
> receiving the events on the option elements.  Then they add a
> mySel.removeAttribute("size") call and suddenly their event handlers
> stop working?!
> 
> That makes no sense to me!
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: jar: URIs from content

[Gregory Szorc]

On Thu, Oct 15, 2015 at 4:08 PM, Robert O'Callahan 
wrote:

> I'm sad that I won't be able to use jar: URLs to load testcases in ZIP
> files uploaded to Bugzilla, but this sounds like the right thing to do.
>

If this is a common use case, then `mach test` should be able to accept a
bz://123456 URL, autodiscover a test case attachment on that bug, download
it, and run it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Jonas Sicking]

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 recommendation after some debating was to do
the above.

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

Re: PSA: Local static analysis builds on Linux and Mac OS X

[Nicholas Nethercote]

On Fri, Oct 16, 2015 at 5:13 AM, Ehsan Akhgari  wrote:
>>
>> Is there an easy way to determine if that package has been installed?
>
> The easiest way is to turn it on in a build and see if the build succeeds.

On my stock Ubuntu 15.04 box it failed...

>> And if it's not installed, is there an easy way to install it?
>
> The answer there depends on the distro.  I think on Ubuntu it is
> libclang-devel, I think.

... so I tried this. The correct package name is "libclang-dev".

I then got a build failure "cannot find -ledit". Some googling
suggested that I install "libedit-dev" and then it worked. (At least,
compilation finished successfully.)

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

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

[Anne van Kesteren]

On Thu, Oct 15, 2015 at 11:00 PM, Mike Conley  wrote:
> Are there any objections or thoughts about this plan?

You should check what the HTML standard says and file an issue if it
doesn't match what you want browsers to do.


-- 
https://annevankesteren.nl/
___
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

[Jonas Sicking]

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 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.
>
> I don't think it's specific to Firefox OS. FOUC is a pretty well researched 
> problem and we have spent a lot of time designing standards to limit the risk 
> of them happening.
>
> The problem is that all we take into account when building anti-FOUC 
> heuristics is HTML+CSS, while in the modern Web Apps, JS is part of the 
> bootstrap process.

I agree with a lot of the above. I would recommend reaching out to
Martin Best and getting this on his backlog of items that we need in
order to create more beautiful webapps.

/ Jonas
___
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

[Vivien Nicolas]

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?
>

For what it worth, I have started to play with background_color in bug
1215077.

It looks cool, and I really like it. But because of the FirefoxOS UX which
displays an icon on top of the defined background color, it is not enough
by itself for most apps.

For example with the calendar app, we will end up with:
 - Orange background with Calendar icon in the middle
 - Orange background from the app without an icon (the app can likely add
that but it starts to become very UA specific)
 - App content.

But generally it is nice and I would like to support that on FirefoxOS.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Please do not use the Date type in Web IDL APIs

[Boris Zbarsky]

This is especially a reminder to reviewers, but also to anyone 
participating in spec discussions.  For context, see 
.  You should 
consider the Date type deprecated and not use it in new specifications. 
 You should _especially_ not create attributes of type Date.


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

Is that possible to use Cc["@mozilla.org/docshell; 1"] to downloading html URI as blob?

[Yonggang Luo]

For example, I am using the following code to fetch the mime parsed HTML flie:

let messageService = MailServices.messenger.messageServiceFromURI(uri);
let docshell = Cc["@mozilla.org/docshell;1"].createInstance(Ci.nsIDocShell);
messageService.DisplayMessage(uri, docshell, MailServices.msgWindow,
null, null, {});

But I don't know how to do that.


-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

[Mike Taylor]

Hi Mike,

On 10/15/15 4:00 PM, Mike Conley wrote:

That’s when I found out that event behaviour for ’s is not spec’d
out, and the way in which events are fired differs widely from browser to
browser.

I tested Firefox Nightly (non-e10s), Safari, Chrome, Internet Explorer and
Edge, and posted my findings at [2].

What I’m proposing is that we try to converge with Chrome / Blink’s
behaviour on these events, where we do not fire any events on ’s,
ever, whenever e10s is enabled by default.


 seems relevant -- 
we don't fire click events on s in Fennec either (because I 
forgot to land the very first patch I wrote, lol?).


AFAIK, there has been no compat fallout from not supporting this.

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

[Mike Conley]

>> Why should the behavior be different with non-drop-down select elements?

The difference in behaviour is something that the other browsers _do_
seem to agree upon. When the  elements are inline (with the
multiple attribute, or size attribute set to > 1), it seems from my
testing that all browsers seem to fire events for mouseover, mousedown,
keyup, keydown, etc.

It's only the dropdown case that seems to be special for each browser -
likely due to the fact that the spec is vague for that case.

On 2015-10-16 10:20 AM, Ehsan Akhgari wrote:
> On 2015-10-15 5:00 PM, Mike Conley wrote:
>> Note that this should not affect Gecko’s behaviour when the  is
>> displayed “inline” (for example, when the  has a “multiple”
>> attribute, or a “size” attribute with a value greater than 1). I'm only
>> concerned with the dropdown case.
> 
> Why should the behavior be different with non-drop-down select elements?
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Local static analysis builds on Linux and Mac OS X

[Ehsan Akhgari]

On 2015-10-16 2:09 AM, Nicholas Nethercote wrote:

On Fri, Oct 16, 2015 at 5:13 AM, Ehsan Akhgari  wrote:


Is there an easy way to determine if that package has been installed?


The easiest way is to turn it on in a build and see if the build succeeds.


On my stock Ubuntu 15.04 box it failed...


And if it's not installed, is there an easy way to install it?


The answer there depends on the distro.  I think on Ubuntu it is
libclang-devel, I think.


... so I tried this. The correct package name is "libclang-dev".

I then got a build failure "cannot find -ledit". Some googling
suggested that I install "libedit-dev" and then it worked. (At least,
compilation finished successfully.)


That's great to know, thanks for reporting this!

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

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

[Ehsan Akhgari]

On 2015-10-15 5:00 PM, Mike Conley wrote:

Note that this should not affect Gecko’s behaviour when the  is
displayed “inline” (for example, when the  has a “multiple”
attribute, or a “size” attribute with a value greater than 1). I'm only
concerned with the dropdown case.


Why should the behavior be different with non-drop-down select elements?

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

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

[Mike Conley]

>> You should check what the HTML standard says and file an issue if it> 
>> doesn't match what you want browsers to do.

Unfortunately, the HTML standard doesn't say much with respect to what
events  elements are supposed to fire, and when.

Once we come to a conclusion here, perhaps I'll work with you to hammer
out that part of the spec.

On 2015-10-16 4:12 AM, Anne van Kesteren wrote:
> On Thu, Oct 15, 2015 at 11:00 PM, Mike Conley  wrote:
>> Are there any objections or thoughts about this plan?
> 
> You should check what the HTML standard says and file an issue if it
> doesn't match what you want browsers to do.
> 
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Martin Thomson]

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:
https://github.com/w3c/webrtc-pc/issues/324

I didn't read all the discussion, but what is wrong with treating Date
as a primitive type that happens to have methods?  I know that it
likely sucks to have all that custom code, but I've seen worse.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Domenic Denicola]

On Friday, October 16, 2015 at 3:12:05 PM UTC-4, Jonas Sicking wrote:
> 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 recommendation after some debating was to do
> the above.
> 
> / Jonas

I've added this and other related guidance to 
https://w3ctag.github.io/design-principles/#times-and-dates, which might help 
as a reference for if/when this comes up again. (Suggested fixes or 
elaborations welcome.)

I also opened https://github.com/heycam/webidl/issues/66 to see if we can make 
this more clear on the spec level.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: jar: URIs from content

[Robert O'Callahan]

On Sat, Oct 17, 2015 at 6:13 AM, Gregory Szorc  wrote:

> On Thu, Oct 15, 2015 at 4:08 PM, Robert O'Callahan 
> wrote:
>
>> I'm sad that I won't be able to use jar: URLs to load testcases in ZIP
>> files uploaded to Bugzilla, but this sounds like the right thing to do.
>>
>
> If this is a common use case, then `mach test` should be able to accept a
> bz://123456 URL, autodiscover a test case attachment on that bug, download
> it, and run it.
>

Not as convenient as clicking on a link.

I guess the right fix would be to have a Web proxy service that accepts
URLs in a custom format, unpacks ZIP files and serves their contents.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Jonas Sicking]

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:
> https://github.com/w3c/webrtc-pc/issues/324
>
> I didn't read all the discussion, but what is wrong with treating Date
> as a primitive type that happens to have methods?  I know that it
> likely sucks to have all that custom code, but I've seen worse.

The problem is that they are mutable objects, with no way to make them
immutable.

So you can do:

file.lastModifiedDate.setYear(3015);

Which means that any other consumers will now see the "wrong" date.
And if you change the attribute getter to return a new Date object
each time, then

file.lastModifiedDate == file.lastModifiedDate;

returns false which is surprising.

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

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

[Boris Zbarsky]

On 10/16/15 12:20 PM, Martin Thomson wrote:

https://github.com/w3c/webrtc-pc/issues/324


Yes, that is what prompted my mail.  ;)


I didn't read all the discussion, but what is wrong with treating Date
as a primitive type that happens to have methods?


The fact that in JS it's not?  It's an object.  That's just the way that 
particular part of the JS standard library works.



I know that it
likely sucks to have all that custom code, but I've seen worse.


I'm not sure what custom code you're talking about.  What exactly are 
you proposing?


-Boris

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