Updates to Bugzilla components for Bugzilla
I've updated the components for bugzilla.mozilla.org in Bugzilla today. All the active components now have triage owners, and the BMO team will be reviewing open bugs in these components (yes, the bugmaster needs to triage her bugs. ) We'll be cleaning up the obsolete components over the next few days. If you got mail because of the cleanup, it was related to a secure bug in the component which you either filed or were cc'ed on. Almost all these were bugs which have been closed. If you have questions about where to file a bug against Bugzilla, please check in #bmo on slack, or contact me. Thanks, Emma Humphries, Bugmaster Firefox ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to deprecated: mfenced element
Hi, In bug 1587577, I intend to add a deprecation warning and use counter for the mfenced element. The MathML Refresh CG has agreed it should not be in core. It is redundant with mrow + mo, its implementation has bugs and adds complexity. -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Elements no longer have a QueryInterface method in JS
This is great. dragana On Tue, Oct 15, 2019 at 4:15 AM Boris Zbarsky wrote: > Hello all, > > Now that we no longer have xbl implements="" to worry about, I have > landed patches to remove the QueryInterface method from Element > instances [1] and the infrastructure for exposing QueryInterface on Web > IDL objects in general [2]. There may still be cases in which custom > element implementations implement QueryInterface on elements, but that's > handled entirely on the JS side, without involving C++ code in any way. > > I checked that there are no calls to the C++ QueryInterface anywhere in > our tests and did some basic code-searching to make sure I didn't find > any, but there might in theory be issues with codepaths which are not > tested in automation... > > -Boris > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1568883 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1568249 > ___ > 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: Elements no longer have a QueryInterface method in JS
Huzzah! So excited to see all this going away. On Mon, Oct 14, 2019 at 7:15 PM Boris Zbarsky wrote: > Hello all, > > Now that we no longer have xbl implements="" to worry about, I have > landed patches to remove the QueryInterface method from Element > instances [1] and the infrastructure for exposing QueryInterface on Web > IDL objects in general [2]. There may still be cases in which custom > element implementations implement QueryInterface on elements, but that's > handled entirely on the JS side, without involving C++ code in any way. > > I checked that there are no calls to the C++ QueryInterface anywhere in > our tests and did some basic code-searching to make sure I didn't find > any, but there might in theory be issues with codepaths which are not > tested in automation... > > -Boris > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1568883 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1568249 > ___ > 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
Intent to deprecate: MathML bevelled attribute
Hi, In bug 1587572, I intend to add a deprecation warning and use counter for the bevelled attribute on the mfrac element. Although the MathML Refresh CG has not reached a consensus about this yet, it is good to try to determine how much this attribute is actually used. -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to deprecate: MathML subscriptshift and superscriptshift attributes
Hi, In bug 1587570, I intend to add a deprecation warning and use counter for the subscriptshift and superscriptshift attributes. Although the MathML Refresh CG has not reached a consensus yet about this, it is good to try to determine how much these attribute are actually used. -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: MathML3 support for semantics and maction elements
Hi, In bug 1588733, I intend to replace MathML3's implementation of the semantics and maction elements with the simple one described in MathML Core. These elements basically provide some complex way to select the one of their children to render (which in practice is just the first one). In addition maction allows some interactive math. These features are better implemented in CSS/JS. -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to prototype: Web Speech API
On Tue, Oct 15, 2019 at 2:56 AM Andre Natal wrote: > Regarding the UI, yes, the experience will be exactly the same in our case: > the user will get a prompt asking for permission to open the microphone (I've > attached a screenshot below [3]) ... > [3] > https://www.dropbox.com/s/fkyymiyryjjbix5/Screenshot%202019-10-14%2016.13.49.png?dl=0 Since the UI is the same as for getUserMedia(), is the permission bit that gets stored the same as for getUserMedia()? I.e. if a site obtains the permission for one, can it also use the other without another prompt? If a user understands how WebRTC works and what this piece of UI meant for WebRTC, this UI now represents a different trust decision on the level of principle. How intentional or incidental is it that this looks like a getUserMedia() use (audio goes to where the site named in the dialog decides to route it) instead of surfacing to the user that this is different (audio goes to where the browser vendor decides to route it)? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
