Re: sendKeyEvent doesn't support event.key

[Masayuki Nakano]

Yeah, I already documented that in MDN...
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMWindowUtils#sendKeyEvent%28%29

On 2015/10/27 0:48, smaug wrote:

On 10/26/2015 10:21 AM, Amit Zur wrote:

MDN says keyCode is deprecated and web developers should favor `key`
instead. But sendKeyEvent doesn't support key property on the event.
I found bug #1214993 but the solution there is a workaround for the
home button for TV.

Can we expect this to be fixed any time soon?




You probably want to use
http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsITextInputProcessor.idl


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



--
Masayuki Nakano 
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Henri Sivonen]

On Fri, Oct 23, 2015 at 9:45 PM, Bobby Holley  wrote:
> On Fri, Oct 23, 2015 at 11:17 AM, Joshua Cranmer 🐧 
> wrote:
>
>> I also wonder why you have a peculiar insistence that comm-central code
>> must not appear to any contributor, given the continued existence of "stuff
>> that Firefox doesn't care about" in mozilla-central, such as support for
>> tier-3 platforms (do we still have QT code in the tree) or xulrunner.
>
>
> FWIW, I personally think we should remove things things from the tree.

I think we shouldn't remove Qt support from the tree. Jolla ships a
Qt-based Gecko-based browser. Sure, their market share is tiny, but
they are still contributing to making Gecko *in a Web browser* (as
opposed to an email client or something else non-Web) available to
more mobile users and they do a better job at delivering updates than
FxOS vendors do. I think it's very sad that they have to do it without
support from us and that they feel like they need to tweet
https://twitter.com/zzste/status/433236310816333824 and retweet from
their corporate Twitter account only to be ignored.

If anything, I think we should make it easier for them to do their
thing on m-c (not as tier-1, of course) and count their contribution
to the delivery of Gecko in a browser to users on mobile towards our
stats regarding reaching users on mobile.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Henri Sivonen]

On Tue, Oct 27, 2015 at 10:04 PM, Boris Zbarsky  wrote:
> On 10/23/15 8:32 PM, Robert O'Callahan wrote:
>>
>> I support merging c-c into m-c.
>
>
> For what it's worth, I do as well.  Of course I also do some due diligence
> about not breaking Thunderbird before landing patches, just like I do for
> Firefox extensions and whatnot and I feel that that is the morally right
> thing to do, at least for me.

I support the merge.

I do have technical worries about Thunderbird being able to adapt to
upcoming Firefox-side changes (every time I make Gecko changes that
affect Thunderbird, the C++ code on the c-c side looks more crufty
than the m-c code from 1999 that I'm dragging closer to the present
day), but I feel we have to find a way for Thunderbird to stay afloat
*for its users*. I don't want us to undermine the trust that nearly 10
million people place in Mozilla and the tone with which those nearly
10 million people talk about Mozilla to others.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation/dev team/dev evangelism meeting Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific DAYLIGHT Time (see http://bit.ly/1GghwBR for
your time zone). Please note that the United States has not yet
transitioned to Daylight Saving Time, so this meeting may be offset by
an hour from its usual start in your area.

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://public.etherpad-mozilla.org/p/API-docs-meeting-2015-10-29.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla 
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR

[Gervase Markham]

On 26/10/15 19:19, Kearwood "Kip" Gilbert wrote:
> As of Oct 29, 2015 I intend to turn WebVR on by default for all
> platforms. It has been developed behind the dom.vr.enabled preference. 
> A compatible API has been implemented (but not yet shipped) in Chromium
> and Blink.

At one point, integrating with available hardware required us to use
proprietary code. Is shipping proprietary code in Firefox any part of
this plan, or not?

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

Merge moved to Thursday 29th

[Sylvestre Ledru]

Hello,

Because we want to synchronize the release of 42 and 44 devedition (next
Tuesday),
we are planning to perform the merge tomorrow, Thursday.
As a consequence, nightly = 45, aurora = 44 and beta = 43 (42 is already
in release).
This will give us enough time to validate the first aurora build.

I apologize for the very late notice. Of course, we will be friendly
with uplift requests.

Sylvestre


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

LazyLogModule, a thread-safe replacement for declaring a PRLogModuleInfo

[Eric Rahm]

Hi All-

I recently landed a lazily-loaded log module class, LazyLogModule [1],  
suitable for declaring static references to log modules in a thread-safe way. 

Currently this class is opt-in and PRLogModuleInfo can still be used w/ 
MOZ_LOG. But be forewarned, as we move forward to a glorious world where log 
levels can be dynamically updated w/o restarting the browser, PRLogModuleInfo 
will be left behind and only LogModule instances will get the benefit.

Before:
===

  PRLogModuleInfo*
  GetMyLog()
  {
static PRLogModuleInfo* sLogModule = PR_NewLogModule("MyLog");
return sLogModule;
  }

  void Foo() { MOZ_LOG(GetMyLog(), ...); }

Now:


  LazyLogModule sMyLogModule("MyLog");

  void Foo() { MOZ_LOG(sMyLogModule, ...); }

The Future:
===

We have already converted xpcom over to using it [2] and are quite happy with 
how things turned out.

This is where you come in dear reader!

Please switch over your PRLogModuleInfo instances to LazyLogModule. I have a 
tracking bug [3] for the overall code base and have split out bugs for smaller 
chunks. If you intend to help out just go ahead and assign yourself one of 
those bugs!

Addendum on Thread Safety
=

There are some common mistakes that TSan runs are tripping over, such as:

// Not-quite-right use of static initialization
GetLog() {
  static* myLog = nullptr; // This is thread-safe on modern compilers
  if (!myLog)
myLog = ... // This is not.
}

// Global, initialize wherever it's used
static PRLogModuleInfo* myLog;

Foo::Foo() {
  if (!myLog)
myLog = ...
}

And to round it out, PR_NewLogModule is not thread-safe [4].

-e

[1] 
https://dxr.mozilla.org/mozilla-central/rev/fc706d376f0658e560a59c3dd520437b18e8c4a4/xpcom/base/Logging.h#100
[2] https://hg.mozilla.org/mozilla-central/rev/f9cf413cb3da
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1219461
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1073578
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Making tests e10s compatible

[Blake Kaplan]

Hello everybody,

You might have heard that we're working on getting our testing situation in
line for e10s. To help people get started, I'm compiling a list of tips
that are useful to know when working on e10s tests (and e10s in general).
You can find it at .

There isn't a catch-all solution to use to fix these tests, but there are a
few things to look out for. The key is to find places in tests where
objects from both chrome (like browser DOM nodes or chrome windows, etc.)
and content (docshells, content windows, etc.) are needed and to use
SpecialPowers or ContentTask to remote that bit to the other process.

If a test is disabled because of a bug in e10s, please ensure that a bug is
on file and the e10s team has triaged it.

I'm happy to answer questions as needed.
-- 
Blake
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merge moved to Thursday 29th

[Ehsan Akhgari]

On 2015-10-28 4:10 PM, Sylvestre Ledru wrote:

Hello,

Because we want to synchronize the release of 42 and 44 devedition (next
Tuesday),
we are planning to perform the merge tomorrow, Thursday.
As a consequence, nightly = 45, aurora = 44 and beta = 43 (42 is already
in release).
This will give us enough time to validate the first aurora build.


We've been working very hard to prepare Service Workers to be released 
in 44.  We're down to a few remaining bugs, and since we were hoping to 
get testing on Aurora on this feature (hopefully with web developers 
experimenting with it!)  I have a couple of questions that would help us 
figure out how this changes our plans (probably not in a great way!).


It would be very helpful if we can get our last changes onto Aurora 
after this uplift.  What's the approval process involved?  Is it the 
same as the normal process?


Also I think this essentially means that we would have no chance to get 
our changes into the first Aurora build.  So we would need to rely on 
the updates.  Are Aurora updates made nightly these days or are there 
small "releases" on the Aurora branch?


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

Re: Merge moved to Thursday 29th

[Byron Jones]

Sylvestre Ledru wrote:

Because we want to synchronize the release of 42 and 44 devedition
(next Tuesday), we are planning to perform the merge tomorrow,
Thursday. As a consequence, nightly = 45, aurora = 44 and beta = 43
(42 is already in release). This will give us enough time to validate
the first aurora build.

I apologize for the very late notice. Of course, we will be friendly
with uplift requests.


please update https://wiki.mozilla.org/RapidRelease/Calendar and the 
associated ICS files.


thanks.
--
byron jones - :glob - bugzilla.mozilla.org team lead -

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

Re: Merge moved to Thursday 29th

[Jonas Sicking]

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 devedition (next
> Tuesday),
> we are planning to perform the merge tomorrow, Thursday.
> As a consequence, nightly = 45, aurora = 44 and beta = 43 (42 is already
> in release).
> This will give us enough time to validate the first aurora build.
>
> I apologize for the very late notice. Of course, we will be friendly
> with uplift requests.
>
> Sylvestre
>
>
> ___
> 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