Re: W3C Proposed Recommendation: IndexedDB 2.0

[Bevis Tseng]

On Thu, Dec 14, 2017 at 2:31 PM Tantek Çelik  wrote:

>
> There is one test row that is red for all implementations, digging into it.
>
> https://wpt.fyi/IndexedDB/idbobjectstore_createIndex15-autoincrement.htm
>
> It looks like there are problems with "Auto-Increment Primary Key",
> specifically:
> * Chrome & Edge fail the test
> * FF & Safari - we don't have results (not sure what just "ERROR" means)
>
>
> 1. For us (Firefox platform) - do we have bugs filed for the tests we
> are failing?
>
>
We have a bug to address this and is under review:
https://bugzilla.mozilla.org/show_bug.cgi?id=1404276
Actually, these failure are not related to anything new in v2 but are
related to more test coverage added from wpt.

>
> Thanks,
>
> Tantek
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: IndexedDB 2.0

[Bevis Tseng]

On Thu, Dec 14, 2017 at 12:05 PM L. David Baron  wrote:

>
> Given that we implement the specification as described in:
> https://hacks.mozilla.org/2016/10/whats-new-in-indexeddb-2-0/
> and that Bevis (who implemented it) agrees, I intend to vote in
> favor.
>
> These are small improvement of existing IndexedDB APIs wanted by web
developers and are shipped since FF51, so I agree to vote it as proposed
recommendation.

Thanks,
Bevis Tseng
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Problems of Microtasks & Promises in Firefox

[Bevis Tseng]

On Fri, Dec 8, 2017 at 3:21 PM Bevis Tseng  wrote:

> After Bug 1193394 <https://bugzilla.mozilla.org/show_bug.cgi?id=1193394>
> revealed the problem about how Firefox performs microtasks differently from
> what has be specified in HTML standard,
>

A small correction here which is mentioned only in the slides of previous
mail:
Actually, we have had the correct microtask handling since the beginning of
microtasks and it has been used with MutationObserver.
Another different mechanism also called microtask internally was added for
Promises, but it did something very different to the original one.
In bug 1193394, we are migrating the one used with Promise to the one used
with MutationObservers to to improve the conformance to HTML standard.

Regards,
Bevis Tseng
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Problems of Microtasks & Promises in Firefox

[Bevis Tseng]

cgi?id=1415793>: Fix
failure of
mobile/android/components/extensions/test/mochitest/test_ext_activeTab_permission.html
relying on non-comformant Promise handling
Bug 1415796 <https://bugzilla.mozilla.org/show_bug.cgi?id=1415796>: Fix
failure of mobile/android/tests/browser/chrome/test_session_form_data.html
relying with comformant Promise handling
Bug 1415797 <https://bugzilla.mozilla.org/show_bug.cgi?id=1415797>: Fix
failures in dom/network/tests/ with comformant Promise handling

It's really appreciated if there are experts in these failed modules to
look into it because the root cause might not only be the test failure
itself but the wrong implementation relying on the old scheduling behavior.
Then, additional migration work is required to make it behave correctly in
both new/old scheduling to allow the main patch to be landed after all
these failure are fixed.

BTW, if you need face to face discussion during Austin All Hands, please
feel free to ping me on irc (:bevis).

Thanks,
Bevis Tseng
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: IPDL now supports async returns with MozPromise

[Bevis Tseng]

On Thu, Apr 20, 2017 at 11:13 PM, Bevis Tseng  wrote:

>
>
> On Thu, Apr 20, 2017 at 10:15 AM, Bevis Tseng  wrote:
>
>> A soft reminder of using AbstractThread::GetCurrent()/MainThread()
>> ​ after some design change for Quantum-DOM.
>>
>> If this message/callback is to be handled on *the main thread of the
>> content process*, please use the replacement called AbstractMainThreadFor
>> <https://wiki.mozilla.org/Quantum/DOM#AbstractThread::MainThread>
>> instead.
>>
>> If you're in background thread or not in content process, you are totally
>> fine to use AbstractThread::GetCurrent()/MainThread().
>>
>> ​Note: Precisely speaking, AbstractThread::MainThread() can be used in
> the main thread of chrome process instead.
> It shall never been used in background thread. Hope it was not misleading
> in previous email.
>
I should say that AbstractThread::MainThread() can be used for to dispatch
runnables to the main thread​ in chrome process.

P.S. No more explanation at midnight to make thing worse. :/

Regards,
>> Bevis Tseng
>>
>>
>> On Thu, Apr 20, 2017 at 2:54 AM, Kan-Ru Chen  wrote:
>>
>>> Hello!
>>>
>>> With bug 1313200 landed, async IPC messages can now return data via
>>> MozPromises.
>>>
>>> The IPDL syntax:
>>>
>>> protocol PFoo {
>>> child:
>>> async Bar() returns (bool param);
>>> };
>>>
>>> will generate IPC code that allow the send method like this:
>>>
>>> SendBar()->Then(AbstractThread::GetCurrent(), __func__,
>>> [](bool param) {
>>>   // do something
>>> },
>>> [](PromiseRejectReason aReason) {
>>>   // handle send failure
>>> });
>>>
>>> For a message named Foo it will receive a promise resolver with type
>>> FooPromise. For example the receiving side of previous message
>>> PFoo::Bar the handler looks like this:
>>>
>>> mozilla::ipc::IPCResult
>>> FooChild::RecvBarMessage(RefPtr&& aPromise)
>>> {
>>> bool result;
>>> // do some computation
>>> aPromise->Resolve(result);
>>> }
>>>
>>> If there are multiple return values, they will be wrapped in a
>>> mozilla::Tuple.
>>>
>>> The usual MozPromise rule applies. You can store the promise and
>>> resolve it later. You can direct the ThenFunction to be run on other
>>> threads. If the channel is closed before all promises are resolved,
>>> the pending promises will be rejected with
>>> PromiseRejectReason::ChannelClosed. Promises resolved after channel
>>> close are ignored.
>>>
>>> It is discouraged for the receiving handler to reject the promise. It
>>> should be reserved for the IPC system to signal errors. If you must
>>> reject the promise, only PromiseRejectReason::HandlerRejected is valid
>>> value.
>>>
>>> Please give it a try. In theory this should work for all IPC actors. If
>>> you encountered issues or have ideas to
>>> improve this, please file a bug in Core :: IPC.
>>>
>>> Thanks,
>>> Kanru
>>>
>>> P.S. Note that async constructor or destructor does not support return
>>> promises because the semantic is still not clear.
>>> ___
>>> 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: IPDL now supports async returns with MozPromise

[Bevis Tseng]

On Thu, Apr 20, 2017 at 10:15 AM, Bevis Tseng  wrote:

> A soft reminder of using AbstractThread::GetCurrent()/MainThread()
> ​ after some design change for Quantum-DOM.
>
> If this message/callback is to be handled on *the main thread of the
> content process*, please use the replacement called AbstractMainThreadFor
> <https://wiki.mozilla.org/Quantum/DOM#AbstractThread::MainThread> instead.
>
> If you're in background thread or not in content process, you are totally
> fine to use AbstractThread::GetCurrent()/MainThread().
>
> ​Note: Precisely speaking, AbstractThread::MainThread() can be used in the
main thread of chrome process instead.
It shall never been used in background thread. Hope it was not misleading
in previous email.

> Regards,
> Bevis Tseng
>
>
> On Thu, Apr 20, 2017 at 2:54 AM, Kan-Ru Chen  wrote:
>
>> Hello!
>>
>> With bug 1313200 landed, async IPC messages can now return data via
>> MozPromises.
>>
>> The IPDL syntax:
>>
>> protocol PFoo {
>> child:
>> async Bar() returns (bool param);
>> };
>>
>> will generate IPC code that allow the send method like this:
>>
>> SendBar()->Then(AbstractThread::GetCurrent(), __func__,
>> [](bool param) {
>>   // do something
>> },
>> [](PromiseRejectReason aReason) {
>>   // handle send failure
>> });
>>
>> For a message named Foo it will receive a promise resolver with type
>> FooPromise. For example the receiving side of previous message
>> PFoo::Bar the handler looks like this:
>>
>> mozilla::ipc::IPCResult
>> FooChild::RecvBarMessage(RefPtr&& aPromise)
>> {
>> bool result;
>> // do some computation
>> aPromise->Resolve(result);
>> }
>>
>> If there are multiple return values, they will be wrapped in a
>> mozilla::Tuple.
>>
>> The usual MozPromise rule applies. You can store the promise and
>> resolve it later. You can direct the ThenFunction to be run on other
>> threads. If the channel is closed before all promises are resolved,
>> the pending promises will be rejected with
>> PromiseRejectReason::ChannelClosed. Promises resolved after channel
>> close are ignored.
>>
>> It is discouraged for the receiving handler to reject the promise. It
>> should be reserved for the IPC system to signal errors. If you must
>> reject the promise, only PromiseRejectReason::HandlerRejected is valid
>> value.
>>
>> Please give it a try. In theory this should work for all IPC actors. If
>> you encountered issues or have ideas to
>> improve this, please file a bug in Core :: IPC.
>>
>> Thanks,
>> Kanru
>>
>> P.S. Note that async constructor or destructor does not support return
>> promises because the semantic is still not clear.
>> ___
>> 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: IPDL now supports async returns with MozPromise

[Bevis Tseng]

A soft reminder of using AbstractThread::GetCurrent()/MainThread()
​ after some design change for Quantum-DOM.

If this message/callback is to be handled on *the main thread of the
content process*, please use the replacement called AbstractMainThreadFor
<https://wiki.mozilla.org/Quantum/DOM#AbstractThread::MainThread> instead.

If you're in background thread or not in content process, you are totally
fine to use AbstractThread::GetCurrent()/MainThread().

Regards,
Bevis Tseng


On Thu, Apr 20, 2017 at 2:54 AM, Kan-Ru Chen  wrote:

> Hello!
>
> With bug 1313200 landed, async IPC messages can now return data via
> MozPromises.
>
> The IPDL syntax:
>
> protocol PFoo {
> child:
> async Bar() returns (bool param);
> };
>
> will generate IPC code that allow the send method like this:
>
> SendBar()->Then(AbstractThread::GetCurrent(), __func__,
> [](bool param) {
>   // do something
> },
> [](PromiseRejectReason aReason) {
>   // handle send failure
> });
>
> For a message named Foo it will receive a promise resolver with type
> FooPromise. For example the receiving side of previous message
> PFoo::Bar the handler looks like this:
>
> mozilla::ipc::IPCResult
> FooChild::RecvBarMessage(RefPtr&& aPromise)
> {
> bool result;
> // do some computation
> aPromise->Resolve(result);
> }
>
> If there are multiple return values, they will be wrapped in a
> mozilla::Tuple.
>
> The usual MozPromise rule applies. You can store the promise and
> resolve it later. You can direct the ThenFunction to be run on other
> threads. If the channel is closed before all promises are resolved,
> the pending promises will be rejected with
> PromiseRejectReason::ChannelClosed. Promises resolved after channel
> close are ignored.
>
> It is discouraged for the receiving handler to reject the promise. It
> should be reserved for the IPC system to signal errors. If you must
> reject the promise, only PromiseRejectReason::HandlerRejected is valid
> value.
>
> Please give it a try. In theory this should work for all IPC actors. If
> you encountered issues or have ideas to
> improve this, please file a bug in Core :: IPC.
>
> Thanks,
> Kanru
>
> P.S. Note that async constructor or destructor does not support return
> promises because the semantic is still not clear.
> ___
> 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: Quantum Flow Engineering Newsletter #4

[Bevis Tseng]

On Sat, Apr 8, 2017 at 6:03 AM, Chris Peterson 
wrote:

>
> Are the bugs to label runnables good for volunteer contributors? Or would
> it be fastest for a DOM expert or engineers from each module to rip through
> the open bugs? Do we need to ask module owners to prioritize these bugs? :)
>
> https://bugzilla.mozilla.org/showdependencytree.cgi?id=13218
> 12&hide_resolved=1
>
> ​It will be faster for the engineers from each module to check these bugs
that are unassigned yet. The reason will be explained later.
​The latest analysis in
https://bugzilla.mozilla.org/show_bug.cgi?id=1333984#c11
gives us some hint to prioritize these bugs even though some runnables are
still anonymous.

According to a searchfox search for unlabeled runnable calls (using the
> function names billm provided), there are still over 800 unlabeled
> runnables:
>
> http://searchfox.org/mozilla-central/search?q=%5CbNS_Dispatc
> hTo(Main%7CCurrent)Thread+*%5C(&case=true®exp=true&path=
> 
>
> ​This is only the first glance for labeling runnables but not all of them
has to be labeled.

​The reasons why we need engineers instead of volunteers to check first are
that
1. All runnables needed to be labeled are the runnables ​dispatched to
the *main
thread of the content process*.
2. In addition to *NS_Dispatch(Main|Current)Thread*, there are several ways
to trigger a runnable to the main thread implicitly:
  - Any calls to the *Dispatch() method of the subclass of nsIEventTarget*.
  - The use of *AbstractThread::MainThread()* (Most of them shall be
covered in bug 1314833)
  - The use of *nsITimer*. (The timer callback will be called by a runnable
to the current thread according to nsTimer implementaiton).
  - Handled the received messages in* IPC actor childs*.
(A received message will be handled on main thread if its actor child
is created on the main thread.)
  - Subclass of *nsExpirationTracker *
   (Bugs of 1347823 ,
1350676 , 1350677
, 1350678
, 1350828
, 1351639
, 1351869
 are created for
tracking this)
  - the use of *NS_New(In|Out)putStreamReadyEvent* or the use of *AsyncWait*()
on the *(In|Out)putStream* acquired from *new Pipe()* in js or
*NS_NewPipe()* in native implementaiton. (These 2 use cases trigger
runnables named "(In|Out)putStreamReadyEvent" to the specified
nsIEventTarget which needs to be labeled if the nsIEventTarget points to
the main thread.)

Hence, we can expect that the scope in some of these labeling bugs are big.
Once engineers of each module break down them into more specific tasks, we
can get help from volunteer easier.

There are several meta bugs as good examples for breaking down these
labeling tasks per module:
Bug 1339343 
(Layout-labeling)
Bug 1339676 
 (Netwerk-labeling)
Bug 1341537 
(gfx-labeling)
Bug 1341539 
(labeling in dom/media)

___
> 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: [WebAPI] New Proposal of IMS Registration Manager

[Bevis Tseng]

On Wed, Jul 22, 2015 at 11:06 PM, Jonas Sicking  wrote:

> On Wed, Jul 22, 2015 at 3:38 AM, Bevis Tseng  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 Navigator, since it's only related to the IMS
> > registration and is also suitable to be part of MozMobileConnection that
> > already available in Navigator.
>
> As long as the API is only exposed to certified content, and is
> completely hidden from other pages, then I think you should feel free
> to put the API whereever in the DOM that makes most sense to you.
>

​Yes, the API is only available to certified content.
After further consideration, we think that it's more suitable to be
part of MozMobileConnection which is responsible for the control
of the features provided in mobile network.

If it turns out to be a problem in the future we can always modify the
> API later.
>
> I do agree with Martin that there's no point in 'moz' prefixing it,
> but I don't have a strong opinion either way.
>

​Will do.​


​Thanks for all your feedback about this API. :)

Bevis​


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

Re: [WebAPI] New Proposal of IMS Registration Manager

[Bevis Tseng]

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 Navigator, since it's only related to the IMS
registration and is also suitable to be part of MozMobileConnection that
already available in Navigator.

Bevis


On Wed, Jul 22, 2015 at 4:57 PM, Martin Thomson  wrote:

> I think that building these sorts of features into the web platform at
> large is a very bad idea.
>
> I appreciate that we operate under different constraints for Firefox
> OS devices that might have native support for IMS on the baseband chip
> and that we don't have much hope of convincing the industry of their
> folly.  As a certified-only extension, it's still bad, but I recognize
> that it may be an inevitability.  Drop the moz/Moz prefixing though.
>
> (I don't have enough time to go through this immediately: my time over
> the next two weeks is highly constrained, so forgive me for not
> engaging in this thread to the extent that you might like.)
>
> On Tue, Jul 21, 2015 at 11:50 PM, Bevis Tseng  wrote:
> >
> > Hi all,
> >
> > I am from RIL team in Mozilla Taipei.
> > I'm glad to propose you a new module/web api called "IMS Registration
> > Manager". It is worth sharing you the details and having suggestion
> > and feedback from you! :)
> >
> > IMS(IP Multimedia Subsystem) is a new infrastructure and is very
> > important in mobile network especially for the carriers that enable
> > LTE which relies more on IP-based network and technology compared to
> > circuit-switched one in 3G/2G mobile network.
> >
> > With IMS enabled, carriers start to migrate current telephony services
> > (Call Control, Text messaging) from legacy network to reduce the
> > the maintenance expense on multiple infrastructures(LTE, GSM, CDMA).
> > The mirgation takes couple of years. That means multiple technology
> > will coexist for a while. Hence, an additional option for user to
> > toggle this feature in device side becomes required from both
> > carrier's and device vendor's perspective.
> > In addition to traditional services, with IMS, carriers can introduce
> > rich communication services like video call, video sharing, presence
> > and instant-messaging to the users.
> >
> > This is also a big task to enable IMS in device side, so we'd like to
> > work on this step by step. Introducing "IMS Registration Manager" is
> > the first step to provide user 2 additional options in settings:
> > 1. To enable/disable IMS.
> >There is no obvious difference from UX perspective when making
> >voice call or text messaging even the underlying technology is
> >changed.
> >(Note: audio quality will be better because AMR-WB is introduced.)
> > 2. To choose the preferred IMS Porfile to have better service
> >quality according to the network condition where the device user
> >is located. The device will register to IMS network with preferred
> >bearrer that user seleted. Possible options are:
> >[wifi-preferred, wifi-only, cellular-preferred, cellular-only]
> >
> > Based on these requirements, the following webidl is proposed:
> >
> > enum ImsCapability {
> >   "voice-over-cellular",
> >   "voice-over-wifi",
> >   "video-over-cellular",
> >   "video-over-wifi"
> > };
> >
> > enum ImsProfile {
> >   "wifi-preferred",
> >   "wifi-only",
> >   "cellular-preferred",
> >   "cellular-only"
> > };
> >
> > interface MozImsRegManager {
> >   getter MozImsRegHandler? handler(unsigned long index);
> >  // with multi-sim support, will be null if not supported
> >  // by the device configuration.
> >
> >   readonly attribute unsigned long length;
> >// with multi-sim supported, the
> >// value will be the same to the
> >// number of service-id/radio
> >// interfaces available in device.
> > };
> >
> > interface MozImsRegHandler : EventTarget {
> > Promise setEnabled(boolean enabled);
> > Promise getEnabled();
> > Promise setPreferredProfile(ImsProfile profile);
> > Promise getPreferredProfile();
> >
> > readonly attribute ImsCapability? capability;
> >   // a

[WebAPI] New Proposal of IMS Registration Manager

[Bevis Tseng]

​​
​​Hi all,

I am from RIL team in Mozilla Taipei.
I'm glad to propose you a new module/web api called "IMS Registration
Manager". It is worth sharing you the details and having suggestion
and feedback from you! :)

IMS(IP Multimedia Subsystem) is a new infrastructure and is very
important in mobile network especially for the carriers that enable
LTE which relies more on IP-based network and technology compared to
circuit-switched one in 3G/2G mobile network.

With IMS enabled, carriers start to migrate current telephony services
(Call Control, Text messaging) from legacy network to reduce the
the maintenance expense on multiple infrastructures(LTE, GSM, CDMA).
The mirgation takes couple of years. That means multiple technology
will coexist for a while. Hence, an additional option for user to
toggle this feature in device side becomes required from both
carrier's and device vendor's perspective.
In addition to traditional services, with IMS, carriers can introduce
rich communication services like video call, video sharing, presence
and instant-messaging to the users.

This is also a big task to enable IMS in device side, so we'd like to
work on this step by step. Introducing "IMS Registration Manager" is
the first step to provide user 2 additional options in settings:
1. To enable/disable IMS.
   There is no obvious difference from UX perspective when making
   voice call or text messaging even the underlying technology is
   changed.
   (Note: audio quality will be better because AMR-WB is introduced.)
2. To choose the preferred IMS Porfile to have better service
   quality according to the network condition where the device user
   is located. The device will register to IMS network with preferred
   bearrer that user seleted. Possible options are:
   [wifi-preferred, wifi-only, cellular-preferred, cellular-only]

Based on these requirements, the following webidl is proposed:

enum ImsCapability {
  "voice-over-cellular",
  "voice-over-wifi",
  "video-over-cellular",
  "video-over-wifi"
};

enum ImsProfile {
  "wifi-preferred",
  "wifi-only",
  "cellular-preferred",
  "cellular-only"
};

interface MozImsRegManager {
  getter MozImsRegHandler? handler(unsigned long index);
 // with multi-sim support, will be null if not supported
 // by the device configuration.

  readonly attribute unsigned long length;
   // with multi-sim supported, the
   // value will be the same to the
   // number of service-id/radio
   // interfaces available in device.
};

interface MozImsRegHandler : EventTarget {
Promise setEnabled(boolean enabled);
Promise getEnabled();
Promise setPreferredProfile(ImsProfile profile);
Promise getPreferredProfile();

readonly attribute ImsCapability? capability;
  // available when ims registered.

readonly attribute DOMString? error;
  // available when the ims is not
  // registration to provide possible
  // error cause.

attribute EventHandler oncapabilitychange;
   // triggered if capability or error is changed.
};

partial interface Navigator {
  [Throws, Pref="dom.ims.enabled",
   CheckPermissions="ims", // or "mobileconnection"
   AvailableIn="CertifiedApps", UnsafeInPrerendering]
  readonly attribute MozImsRegManager mozImsManager;
};

Any suggestion on this is really appreciated. :)

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