Re: What is the Mac bundle id of Firefox?
Thank you, I downloaded the Firefox builds on mozilla.org and verified the CFBundleIdentifier. I believe the relevant ids that we should ask Apple to white list are: org.mozilla.firefox (Firefox release and beta) org.mozilla.firefoxdeveloperedition (Firefox Developer Edition) org.mozilla.nightlydebug and org.mozilla.nightly (nightly, development, & unofficial versions, with and without debug symbols) The "Desktop Boot2Gecko" build available on https://nightly.mozilla.org/ also uses org.mozilla.nightly so I think we really only want https://dxr.mozilla.org/mozilla-central/search?q=MOZ_APP_DISPLAYNAME+path%3Abrowser%2Fbranding=false=true=54=0 Someone on the WebKit dev mailing list mentioned that Apple's Mail application does not have this same "page loaded announcement" behavior, so probably Thunderbird, XULRunner, Instantbird etc should be excluded. I'm not sure about SeaMonkey, since it is really a suite with a browser, mail client, editor etc On 10/02/2015 02:48 PM, Ben Hearsum wrote: > This list looks right to me, based on my memories of dealing with code > signing changes for 10.10. You can confirm this by downloading Nightly, > Aurora, Beta, Release, and ESR and having a look for CFBundleIdentifier > in Contents/MacOS/Info.plist in each. > > On 2015-10-02 07:47 AM, Gijs Kruitbosch wrote: >> The source code says: >> >> https://dxr.mozilla.org/mozilla-central/search?q=MOZ_APP_DISPLAYNAME+path%3Abranding=true=true=63=0 >> >> >> So for the purposes of OS X, I believe the current list is: >> >> Firefox >> Nightly >> FirefoxDeveloperEdition >> B2G >> >> (I *think* there is a way to build b2g stuff on osx into something >> desktoppy (mulet? b2g emulator?), so we might as well include it in the >> list... unless Eitan/others say I'm making stuff up here, in which case, >> just the top 3) >> >> The tricky thing, of course, is that then there are the other usecases: >> >> https://dxr.mozilla.org/mozilla-central/search?q=MOZ_APP_DISPLAYNAME&=mozilla-central=true=63 >> >> >> which means that you may (or may not!) want "XULRunner" or "SeaMonkey" >> or "Instantbird" ( >> https://dxr.mozilla.org/comm-central/search?q=MOZ_APP_DISPLAYNAME=63 >> ) >> >> and I don't know whether you care about those or whether they match what >> you (or Mozilla-the-org, or Apple) would consider "Official" Mozilla >> builds, or whether they would make sense as "web browser" things (which >> is more clear for things like SeaMonkey than for Instantbird or XULRunner). >> >> ~ Gijs >> >> >> >> On 02/10/2015 07:15, Frédéric WANG wrote: >>> Hi all, >>> >>> I've recently tried to fix an accessibility bug on Mac (see >>> https://bugzilla.mozilla.org/show_bug.cgi?id=718637). According to Apple >>> developers, VoiceOver must white list Firefox as a "web browser" so that >>> it can react to AXLoadComplete notifications normally. For that purpose, >>> we need to provide them the Mac bundle id of Firefox. >>> >>> Reading our configure script, MOZ_MACBUNDLE_ID is of the form >>> "org.mozilla.***" or "org.mozilla.***debug" where *** is the lowercased >>> MOZ_APP_DISPLAYNAME build configuration: >>> >>> http://hg.mozilla.org/mozilla-central/file/2c1fb007137d/configure.in#l4588 >>> >>> http://hg.mozilla.org/mozilla-central/file/2c1fb007137d/configure.in#l8679 >>> >>> >>> So actually my question becomes: what is the possible values of >>> MOZ_APP_DISPLAYNAME in the official Mozilla builds? I assume the values >>> include at least "Firefox" and "Nightly". Anything else? >>> >>> Thank you, >>> >>> Frédéric Wang >>> >> > -- Frédéric Wang maths-informatique-jeux.com/blog/frederic signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
What is the Mac bundle id of Firefox?
Hi all, I've recently tried to fix an accessibility bug on Mac (see https://bugzilla.mozilla.org/show_bug.cgi?id=718637). According to Apple developers, VoiceOver must white list Firefox as a "web browser" so that it can react to AXLoadComplete notifications normally. For that purpose, we need to provide them the Mac bundle id of Firefox. Reading our configure script, MOZ_MACBUNDLE_ID is of the form "org.mozilla.***" or "org.mozilla.***debug" where *** is the lowercased MOZ_APP_DISPLAYNAME build configuration: http://hg.mozilla.org/mozilla-central/file/2c1fb007137d/configure.in#l4588 http://hg.mozilla.org/mozilla-central/file/2c1fb007137d/configure.in#l8679 So actually my question becomes: what is the possible values of MOZ_APP_DISPLAYNAME in the official Mozilla builds? I assume the values include at least "Firefox" and "Nightly". Anything else? Thank you, Frédéric Wang signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
What is the Mac bundle id of Firefox?
Hi all, I've recently tried to fix an accessibility bug on Mac (see https://bugzilla.mozilla.org/show_bug.cgi?id=718637). According to Apple developers, VoiceOver must white list Firefox as a "web browser" so that it can react to AXLoadComplete notifications normally. For that purpose, we need to provide them the Mac bundle id of Firefox. Reading our configure script, MOZ_MACBUNDLE_ID is of the form "org.mozilla.***" or "org.mozilla.***debug" where *** is the lowercased MOZ_APP_DISPLAYNAME build configuration: http://hg.mozilla.org/mozilla-central/file/2c1fb007137d/configure.in#l4588 http://hg.mozilla.org/mozilla-central/file/2c1fb007137d/configure.in#l8679 So actually my question becomes: what is the possible values of MOZ_APP_DISPLAYNAME in the official Mozilla builds? I assume there are at least "Firefox" and "Nightly". Anything else? Thank you, Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
What is the Mac bundle id of Firefox?
Hi all, I've recently tried to fix an accessibility bug on Mac (see https://bugzilla.mozilla.org/show_bug.cgi?id=718637). According to Apple developers, VoiceOver must white list Firefox as a "web browser" so that it can react to AXLoadComplete notifications normally. For that purpose, we need to provide them the Mac bundle id of Firefox. Reading our configure script, MOZ_MACBUNDLE_ID is of the form "org.mozilla.***" or "org.mozilla.***debug" where *** is the lowercased MOZ_APP_DISPLAYNAME build configuration: http://hg.mozilla.org/mozilla-central/file/2c1fb007137d/configure.in#l4588 http://hg.mozilla.org/mozilla-central/file/2c1fb007137d/configure.in#l8679 So actually my question becomes: what is the possible values of MOZ_APP_DISPLAYNAME in the official Mozilla builds? I assume there are at least "Firefox" and "Nightly". Anything else? Thank you, Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Use of C++11 std::unique_ptr for the WOFF2 module
Dear all, I'm trying to upgrade our local copy of OTS to version 5.0.0 [1]. OTS relies on the Brotli and WOFF2 libraries, whose source code we currently include in mozilla-cental. I tried updating the source code of WOFF2 to the latest upstream version. Unfortunately, try server builds fail on OSX and mobile devices because the C++11 class std::unique_ptr does not seem to be available. IIUC some bugzilla entries and older threads on this mailing list, at the moment only some of the C++11 features are usable in the mozilla build system. Does any of the build engineer know whether std::unique_ptr can be made easily available? Or should we just patch the WOFF2 library to use of std::vector (as was done in earlier version)? Thanks, -- Frédéric Wang [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1227058 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of C++11 std::unique_ptr for the WOFF2 module
Le 01/02/2016 23:38, Nathan Froyd a écrit : > We're working on moving all of our platforms to use a C++11-ish > standard library. For std::unique_ptr, at least, the best tack is to > write a small polyfill based on mfbt/UniquePtr.h. (It's not clear to > me how your suggestion with std::vector applies here.) If our > UniquePtr isn't a drop-in replacement for std::unique_ptr, that's > worthy of a bug report. > > -Nathan Yes, Lee Salzman gave me such a suggestion (thanks btw). Regarding my suggestion of std::vector: One file in the WOFF2 library is implementing the optimization of OpenType tables and has to manipulate list of points. In previous version this was done using std::vector. For some reason, in the latest upstream version it is now done via a std::unique_ptr<Point[]>. So what I've done is just to go back to the previous implementation. Of course, this only applies to this particular case and is not a general replacement for std::unique_ptr Using UniquePtr or a polyfill base on UniquePtr will probably gives a result closer the author's intention. But at the end we will still have to patch the woff2 library in some way... -- Frédéric Wang signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of C++11 std::unique_ptr for the WOFF2 module
Le 01/02/2016 16:23, Ehsan Akhgari a écrit : > > Also the lack of libc++ on OSX makes this an issue there, which should > explain the OSX issue mentioned above. > Yes, I tried to follow what's done in build/clang-plugin/moz.build This allowed to compile the c++ files but linking failed. -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we remove nsIEntityConverter?
Le 01/05/2016 02:16, smaug a écrit : > What would source view for mathml look like if we removed > nsIEntityConverter? AFAIK, the only point is to replace things like "" with "" in order to make it more readable. However, with appropriate fonts installed I think reading "∑" is also fine. Le 30/04/2016 12:25, Henri Sivonen a écrit : > In desktop Firefox, these data tables are used only for the > MathML View Source feature. Personally, I don't really use this feature, as I find the DOM inspector or the "MathML Copy" add-on (*) more convenient to check or copy a MathML formula. I guess we can move this feature from the Desktop front-end to a separate Add-on (that could potentially work on mobile too in the future). However, I can't speak for the users. Maybe we should write to the Math WG mailing list in order to get more feedback. (*) https://addons.mozilla.org/en-US/firefox/addon/mathml-copy/ -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing "MathML View Source" menu item? [was: Can we remove nsIEntityConverter?]
Le 17/05/2017 à 17:14, J. Ryan Stinnett a écrit : > Looking at the add-on, it seems to miss one feature: Currently in m-c, you > can select a portion of a MathML expression, choose "View Selection > Source", and see the MathML source for the selection. If that's added to > your add-on, I believe you'd have feature parity with the existing MathML > view source support. Right, I had opened https://github.com/fred-wang/webextension-mathml-view-source/issues/7 for missing features. I don't know exactly how important they are, though. > I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1365626 to remove > MathML view source from m-c. Thanks, maybe a first step would be to remove the usage of nsIEntityConverter as Henri indicated as I don't think it's an important feature (this is https://github.com/fred-wang/webextension-mathml-view-source/issues/6). -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Removing "MathML View Source" menu item? [was: Can we remove nsIEntityConverter?]
Le 30/04/2016 à 12:25, Henri Sivonen a écrit : > We ship data tables for converting from Unicode to HTML entities. > These tables obviously take space. (They are not optimized for space > usage, either.) As far as I can tell, these tables are not used at all > in Fennec. In desktop Firefox, these data tables are used only for the > MathML View Source feature. > > Additionally, a subset of the tables is used by some XPCOM-based > extensions, but those extensions seem to be obsolete or abandoned or > don't seem to be using the feature for a very good reason. > > These data tables are not exposed to the Web Platform. > > In https://bugzilla.mozilla.org/show_bug.cgi?id=1048191 I proposed > removing this for mobile only, but how about we just remove this > altogether in order to make both Fennec and desktop Firefox smaller? > Hi, I'm resurrecting this old thread, just to say that there is now a WebExtension implementing the "MathML view source" feature (using better syntax highlighting and handling the invisible spaces too): https://addons.mozilla.org/en-US/firefox/addon/mathml-view-source/ So I'm proposing to remove that feature from the core mozilla source. The only concern I have is for Thunderbird/Seamonkey as it is not clear yet what will be the future regarding WebExtensions. Any opinions? -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: ::-moz-math-anonymous.
On 21/02/2018 19:07, Emilio Cobos Álvarez wrote: > > On 02/21/2018 07:02 PM, Tantek Çelik wrote: >> SGTM. I did not find any references on MDN, so nothing to update there >> AFAIK. >> >> However with a broader web search I found >> https://gist.github.com/yields/6648240 >> >> Is ::-moz-math-anonymous special? (last of its kind?) Or would the >> same reasoning apply to removing access to ::-moz-math-stretchy or any >> of the others in that list? Or is that just an out-of-date list that >> we can ignore? > > Looks out of date to me. ::-moz-math-stretchy was removed four years ago > in https://bugzilla.mozilla.org/show_bug.cgi?id=1000879. Hi Emilio, IIRC, ::-moz-math-stretchy was the only MathML pseudo element that was publicly documented but it's no longer needed now that people can just use font-family and/or the font preference menu to select a math font. It should be safe to stop exposing -moz-math-anonymous and -moz-mathml-anonymous-block, if we do. -- Frédéric Wang - frederic-wang.fr ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MathML Refresh Heads up
Hello Mozilla developers, As some of you may know, Igalia is working on MathML support in Chromium this year [1]. As part of that effort we joined a new MathML Refresh Community Group [2] and one goal is to focus on a core spec for browser implementations [3] to: - Remove deprecated/uncommon/duplicate math features that could be implemented by polyfills (relying on MathML core and other web technologies). - Add more detailed algorithms (based on TeX/OpenType/CSS layout) to help implementation and conformance testing. - Align MathML with CSS/HTML (parsing, layout...), introducing new web platform features (CSS, fonts...) for math if necessary. We expect that this effort will improve browser interoperability and reduce complexity of current implementations. This is just a heads up to say that some work is likely to happen to update/remove/add MathML features. The appropriate "Intents" will be sent later to these mailing lists. Frédéric and Rob, [1] https://mathml.igalia.com/ [2] https://mathml-refresh.github.io/ [3] https://mathml-refresh.github.io/mathml-core/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to deprecate: named values for 's linethickness attribute
Hi, In bug 1548529, I intend to deprecate 's linethickness attribute values "thin", "thick" and "medium" from MathML3. The two first do not specify an exact thickness while the third one is the same as the default value. The MathML CG agreed to remove them from MathML Core and was not able to find any use of it [3]. However, these values are also implemented in WebKit. So for now, the plan is just to introduce a preference to disable them in Nighly build. [1] https://www.w3.org/Math/draft-spec/chapter3.html#id.3.3.2.2 [2] https://github.com/mathml-refresh/mathml/issues/4 [3] https://github.com/mathml-refresh/mathml/issues/55 -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: nonzero unitless MathML lengths
Hi, In bug 1574749, I intend to unship nonzero unitless MathML lengths. MathML 3 says that things like mathsize="2" should be interpreted as mathsize="200%" but discourages that use [1]: > A trailing "%" represents a percent of a reference value; unless otherwise stated, the reference value is the default value. [...] A number without a unit is intepreted as a multiple of the reference value. This form is primarily for backward compatibility and should be avoided, preferring explicit units for clarity. Unitless values have been implemented in WebKit and Gecko. We have sent deprecation warning since Mozilla 20 (released 6 years ago) [2]. MathML2 was less consistent regarding how to handle unitless attribute values but at least "0" is always accepted [3]. The MathML CG agreed to align with CSS and only accept the unitless value "0" in MathML Core [4]. [1] https://www.w3.org/TR/MathML3/chapter2.html#fund.units [2] https://bugzilla.mozilla.org/show_bug.cgi?id=553917 [3] https://www.w3.org/TR/MathML2/chapter2.html#fund.units [4] https://github.com/mathml-refresh/mathml/issues/24 -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to deprecate: named values the mathsize attribute
Hi In bug 1548527, I intend to deprecate mathsize's attribute values "small", "big" and "normal" from MathML3 [1]. The two first do not specify an exact font-size values (and have inconsistent implementations) while the third one is the same as the default value. Incidentally, note that names differ from CSS font-size keywords, which is confusing for users. The MathML CG agreed to remove them from MathML Core and was not able to find any use of it [2] [3]. However, these values are also implemented in WebKit. So for now, the plan is just to introduce a preference to disable them in Nighly build. [1] https://www.w3.org/Math/draft-spec/chapter3.html#presm.commatt [2] https://github.com/mathml-refresh/mathml/issues/7 [3] https://github.com/mathml-refresh/mathml/issues/55 -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: 's mode attribute
Hi, In bug 1573438, I intend to remove support for the mode attribute on the element. This attribute is from MathML 1 and has been deprecated from MathML 2 (released 16 years ago) in favor of the display attribute [1] and we have been sending deprecation warnings since Mozilla 20 (released 6 years ago) [2]. It has never been implemented in WebKit, Igalia does not plan to implement it in Chromium and the MathML Refresh Community Group decided to remove it from MathML Core [3] [1] https://www.w3.org/TR/MathML2/chapter7.html#interf.toplevel [2] https://bugzilla.mozilla.org/show_bug.cgi?id=553917 [3] https://github.com/mathml-refresh/mathml/issues/5 -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: Legacy MathML syntax for numbers
Hi, After the changes mentioned in previous announcements [1] [2] [3] [4], the valid MathML length values are almost a subset of CSS and we could consider relying on the CSS parser in the future. The only remaining difference is in the definition of numbers since MathML3 allows the following case: an optional "-", followed by a nonempty sequence of digits, followed by a dot. For example "42.px" is valid MathML3 length and equivalent to "42px". For details see [5]. The MathML CG decided to align the definition of numbers on CSS [6]. This syntax is supported in WebKit too. However, it seems safe to unship it without deprecation warning since it's really an edge case and it is very unlikely that people/tools would write/generate a number ending with a dot. I plan to do this in bug 1575596. [1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/yEMdIOo4i-0 [2] https://groups.google.com/forum/#!topic/mozilla.dev.platform/kyB34PjYXek [3] https://groups.google.com/forum/#!topic/mozilla.dev.platform/G91-vBeC3Rw [4] https://groups.google.com/forum/#!topic/mozilla.dev.platform/-yV6wb3klSA [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1574751#c2 [6] https://github.com/mathml-refresh/mathml/issues/23 -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to deprecate: mathspace names for MathML lengths
Hi,
In bug 1574750, I intend to deprecate mathspace names for MathML length
values ("thinmathspace", "mediummathspace", "thickmathspace", etc) which
only have suggested values [1].
The MathML CG agreed to remove them from MathML Core as they can be
replaced with equivalent em values [2]. However, they have been
implemented in both WebKit and Gecko and some MathML content & tools use
them, so we will need to be careful. For now, they will only be disabled
in nightly build.
[1] https://www.w3.org/TR/MathML3/chapter2.html#type.namedspace
[2]
https://github.com/mathml-refresh/mathml/issues/75#issuecomment-523016332
--
Frédéric Wang
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intend to deprecate: XLink attributes on MathML elements
On 25/08/2019 00:33, Cameron McCormack wrote: > Thank you for cleaning this up, Frédéric. What are the use counter > thresholds you are looking for with these MathML deprecations? A certain > percentage of all pages, or of pages with any MathML? Emilio re-enabled for Mozilla 68 [1] a counter of pages that contained MathML content rendered by Gecko. This is what we plan to use as a reference. We haven't decided about the exact threshold yet though. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1538985 -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intend to deprecate: XLink attributes on MathML elements
Hi, In bug 1548524, I intend to deprecate XLink attributes (“href”, “type”, “show” and “actuate”) on MathML elements. This has never been supported by other browsers and AFAIK there is not any plan to do so. Gecko actually only has partial support for XLink and there is no plan to implement full support [1]. MathML3 (released 5 years ago) introduced a href attribute as a replacement for xlink:href [2]: "Note that MathML 2 had no direct support for linking, and instead followed the W3C Recommendation 'XML Linking Language' [XLink] in defining links using the xlink:href attribute. This has changed, and MathML 3 now uses an href attribute. However, particular compound document formats may specify the use of XML linking with MathML elements, so user agents that support XML linking should continue to support the use of the xlink:href attribute with MathML 3 as well. " Although MathML 3 still says xlink:href should be supported in user agents supporting XML linking, there is an open item regarding what to do in future versions [3]. We have been sending deprecation for xlink:href on MathML elements for 7 years [4] however users have reported bugs for xlink:href in the past [5] so it is sensible to be a bit more careful. For now these attributes will only be disabled in nightly and a use counter will be introduced to determine how much this feature is used. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=61664 [2] https://www.w3.org/Math/draft-spec/chapter2.html#fund.globatt [3] https://github.com/mathml-refresh/mathml/issues/127 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=553917 [5] e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=427990 -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: Deprecated MathML style attributes
Hi In [1], I mentioned the intent to unship 's mode attribute. In bug 1548524, I'll intend to unship the remaining attributes deprecated in MathML3: fontfamily, fontweight, fontstyle, fontsize, color and background. Actually, these have been deprecated since MathML2 [2] (released 16 years ago) and we have been sending deprecation warnings since Mozilla 20 (released 6 years ago). The MathML CG agreed to removed them from MathML Core [3] and Igalia does not plan to implement them in Chromium. Contrary to the mode attribute, these attributes are also implemented in WebKit [4] and we got bug reports about some of them in the past [5]. Hence, it makes sense to be a bit more careful. For now they will only be disabled in nightly and use counters to determine how much they are used. [1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/lZUF2Z9jOh4/discussion [2] https://www.w3.org/TR/MathML2/chapter3.html#presm.deprecatt [3] https://github.com/mathml-refresh/mathml/issues/5 [4] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/mathml/MathMLElement.cpp#L96 [5] e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1027354 -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: MathML alignment attributes
Hi, In [1] I intend to unship alignment attributes for the mfrac element (numalign, denomalign) and munderover/munder/mover elements (align). They will first be disabled in Nightly and deprecations/counters will be used in other channels. The MathML CG agreed to remove them from the MathML Core spec [2]. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1548530 [2] https://github.com/mathml-refresh/mathml/issues/30 -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: MathML menclose notation "radical"
Hi, In [1] I intend to unship the value "radical" for the notation attribute of the menclose element. It will first be disabled in Nightly and deprecation warnings/counters will be used in other channels. The MathML CG agreed to remove this value from the MathML Core spec [2]. For the record, this notation is used to draw square roots but it essentially duplicates the element which everybody uses instead. After the removal, the layout and drawing logic for mathematical radicals could be shared between and (currently we have two similar implementations for msqrt/menclose on one side and for mroot on the other side). [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1548522 [2] https://github.com/mathml-refresh/mathml/issues/3 -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to prototype: Implement the MathMLElement interface and the corresponding content attributes
Hi everyone,
*Summary*: I'm planning to implement the MathMLElement interface. This
means adding support for new MathML content and IDL attributes (namely,
from the GlobalEventHandlers, DocumentAndElementEventHandlers,
HTMLOrForeignElement, ElementCSSInlineStyle mixins) that already exist
for HTML elements.
The goal is to make MathML less special as explained in
https://bkardell.com/blog/OnePlatform.html. Currently, all MathML
elements just use the Element interface and it is for instance not even
possible to use something like mathmlEl.style to access inline style.
This has been causing concrete issues e.g. in Marionette's testdriver's
implementation (https://bugzilla.mozilla.org/show_bug.cgi?id=1530110) or
in DevTools style rules
(https://bugzilla.mozilla.org/show_bug.cgi?id=1231085).
More generally, as suggested in
https://groups.google.com/forum/#!msg/mozilla.dev.platform/A6rs06cpt7I/0gOinxLvBQAJ
the idea is on the one hand to simplify native MathML implementations to
a core subset and on the other hand to provide to web developers the
necessary APIs to easily enhance it with their own math extensions. The
MathMLElement interface is a first step toward the latter.
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1571487
*Link to standard*:
https://mathml-refresh.github.io/mathml-core/#dom-mathmlelement
https://mathml-refresh.github.io/mathml-core/#attributes-common-to-html-and-mathml-elements
https://github.com/mathml-refresh/mathml/issues/83
https://github.com/whatwg/html/issues/4702
*Platform coverage*: All
*Preference*: No preference for now, as these are not really new
features but really just "normalizing" MathML. However, one preference
can be introduced if people feel it is necessary.
*DevTools bug*:
https://bugzilla.mozilla.org/show_bug.cgi?id=1583020
https://bugzilla.mozilla.org/show_bug.cgi?id=1231085
*Other browsers*:
WebKit: Shipped in r249572 (without flag)
https://github.com/whatwg/html/issues/4702#issuecomment-529172144
https://github.com/mathml-refresh/mathml/issues/83#issuecomment-518398056
Blink: Considering (intent to be emailed in October)
https://www.chromestatus.com/feature/5240822173794304
https://log.csswg.org/irc.w3.org/css/2019-09-17/#e1241535
https://github.com/mathml-refresh/mathml/issues/83#issuecomment-510051714
*web-platform-tests*:
mathml/relations/html5-tree/clipboard-event-handlers.tentative.html
mathml/relations/html5-tree/css-inline-style-dynamic.tentative.html
mathml/relations/html5-tree/css-inline-style-interface.tentative.html
mathml/relations/html5-tree/href-click-3.html
mathml/relations/html5-tree/html-or-foreign-element-interfaces.tentative.html
mathml/relations/html5-tree/math-global-event-handlers.tentative.html
mathml/relations/html5-tree/tabindex-001.html
mathml/relations/html5-tree/tabindex-002.html
This will signicantly increase the Gecko's pass rate on
https://mathml-refresh.github.io/mathml-core/implementation-report.html
*Secure contexts*: Same as HTMLElement IDL.
*Is this feature enabled by default in sandboxed iframes?* Same as
HTMLElement IDL.
*How stable is the spec*: Although MathML Core is still a draft, as said
above these are really attributes that already exist in HTML5/CSSOM
specifications and implemented in all browsers.
*Web designer / developer use-cases AKA Why a developer would use
Feature X?*
- This would make easier to web developers to write interactive MathML
content or write extensions to MathML Core. Currently, it is possible to
implement equivalent behavior but in a more verbose way (consider for
example implementing tab navigation + focus ring for a large math
equation without tabindex).
- When writing generic JavaScript for HTML content, one has to add
special handling to support MathML (cf mentions of Marionette and
DevTools above).
*Example*:
https://people.igalia.com/fwang/blink-on-10/slides/#/12
A very basic demo presented at the last BlinkOn. One could use
MathMLElement.onclick = ... and MathMLElement.style.color = ... to
easily change the color of the red alpha when clicked. Without
MathMLelement, one would use Element.addEventListener(...) and
Element.setAttribute("style", ...) which is a bit more verbose and
probably not how developers would do a quick implementation for "normal"
HTML elements.
--
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 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
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 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
Intent to prototype: Document as explicit root of an intersection observer
Summary: This is an enhancement to the IntersectionObserver API.
Currently, it is possible to use the top level document (implicit root)
or to specify an Element (e.g. {root: document.scrollingElement}). None
of these options provides a way to specify a root corresponding to the
bounding box of an iframe's window. This proposal is about allowing an
explicit Document root, in order to cover that case.
Original intent-to thread:
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/intersectionobserver/mozilla.dev.platform/YdKTMvQygl0/cl2vdYt3BgAJ
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1617154
https://bugzilla.mozilla.org/show_bug.cgi?id=1381574 (meta bug)
Standard:
https://w3c.github.io/IntersectionObserver (specification)
https://github.com/w3c/IntersectionObserver/issues/372 (public discussion)
Platform coverage: All
Preference: dom.IntersectionObserverExplicitDocumentRoot.enabled
DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1617526
https://bugzilla.mozilla.org/show_bug.cgi?id=1347849
Other browsers:
* WebKit:
intent emailed
https://lists.webkit.org/pipermail/webkit-dev/2020-February/031087.html
considering https://bugs.webkit.org/show_bug.cgi?id=208047
* Blink:
intent emailed
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/6dOOw2vu1is
shipped since version 81
https://chromium-review.googlesource.com/c/chromium/src/+/2015676
web-platform-tests:
https://w3c-test.org/intersection-observer/document-scrolling-element-root.html
Secure contexts: Same as IntersectionObserver
Is this feature enabled by default in sandboxed iframes: Same as
IntersectionObserver
As mentioned in the original intent-to thread, the root can be in a
different-origin document so there is some security aspect to consider
here. AFAIK, the proposal does not make the situation worse though. I
can't find any conclusion on the security aspect in the original
intent-to thread, so I guess someone more knowledgeable than me on this
should comment.
--
Frédéric Wang
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: title argument of Navigator.registerProtocolHandler
As of 2020-05-05 I intend to remove the title argument of
Navigator.registerProtocolHandler. It has been removed from the HTML5
specification and none of the existing implementation does something
UI-wise [1]. Status in other browsers is:
* WebKit: Navigator.registerProtocolHandler is not implemented.
* Chromium: Title argument parsed but not used in the browser UI. Bug
opened to remove it [2] and patch + intent to remove to be sent. However
all feature removals are on hold in Chromium, so this one will likely be
delayed too.
Bug to remove: https://bugzilla.mozilla.org/show_bug.cgi?id=1631464
No telemetry analysis has been performed but the argument is likely used
in many pages since it is mentioned in developer documentation and
examples, including MDN. Consequently, it is probably preferable to just
ignore the title argument without spamming the developer console.
The title is not used for the UI so there won't be any observable UI
change for users. It can be using JavaScript but only in cases that are
not done in practice e.g.
navigator.registerProtocolHandler(protocol, url, { toString: () => {
alert('Hello World!'); } });
[1] https://github.com/whatwg/html/pull/5425
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=1072461
--
Frédéric Wang
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: Document as explicit root of an intersection observer
As of 2020-03-23 I intend to turn "Document as explicit root of an intersection observer" on by default on all platforms. It has been developed behind the dom.IntersectionObserverExplicitDocumentRoot.enabled preference. Status in other browsers is: landed in WebKit development build without flag ; shipped in Chromium since version 81. Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1623623 This feature was previously discussed in this "Intent to prototype" thread: https://groups.google.com/forum/#!msg/mozilla.dev.platform/64nDLTAZGzY/CQMV7WqtCAAJ. -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to deprecate: MathML scriptminsize and scriptsizemultiplier attributes
In bug 1548471, I intend to deprecate the MathML scriptminsize and scriptsizemultiplier attributes. These are used to let people provide custom style for a minimal font-size when doing scriptlevel changes or a scale factor to apply to font-size at each scriptlevel change. The MathML Refresh CG agreed to remove these attributes from MathML Core. These attributes don't seem to be used by authoring tools and there does not seem to be any plan to implement them in other browsers. Their effect might still be interesting, but the use cases would likely be better achieve by other means (e.g. making CSS math-depth a float, using OpenType MATH script-related scales, limiting math-depth automatic increment to small values, not putting font-family: math on deep nodes, relying on font.minimum-size.x-math etc). For now, the default scriptminsize="8pt" would still apply but won't be customizable. The plan is to setup telemetry & deprecation warning and then analyze later whether we can remove them. Spec: https://www.w3.org/Math/draft-spec/chapter3.html#presm.mstyle.attrs Decision: https://lists.w3.org/Archives/Public/public-mathml4/2019Apr/0022.html MathML Core analysis: https://github.com/mathml-refresh/mathml/issues/55 -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to prototype: math-depth property and font-size: math
Summary: Implements the math-depth and font-size: math properties which indicate how deep some part of a mathematical formula with respect to the top-level `` and that a scale has to apply to font-size. This is used by MathML to implement automatic scaling in scripts etc, as well as for the scriptlevel attribute. Exposing the magic to CSS provides more flexibility to users and could help to get rid of less used MathML scriptminsize and scriptsizemultiplier attributes (I'll send a follow-up email). scriptlevel has been implemented for a while as an internal CSS -moz-math-depth property. I've been renaming this property and changing the syntax but we need some more tweaks to match the spec. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1667090 Standard: * https://mathml-refresh.github.io/mathml-core/#the-math-script-level-property * https://github.com/w3c/csswg-drafts/issues/5389 Platform coverage: All Preference: layout.css.math-depth.enabled Devtools bug: N/A: no extra work is required for devtools. Other browsers: * Safari: No public signal from Apple. Igalia plans to implement it as part of a MathML interop effort. Bug is https://bugs.webkit.org/show_bug.cgi?id=202303 * Chrome: shipped behind the CSSMathDepth flag ; last patch landed in https://chromium-review.googlesource.com/c/chromium/src/+/2423843 web-platform-tests: https://w3c-test.org/css/css-fonts/math-script-level-and-math-style More tests for invalid, calc(...) and var(...) will be added too. Secure contexts: Like all other CSS selectors these are not restricted to secure contexts. Is this feature enabled by default in sandboxed iframes?: Yes -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to prototype: math-style property
On 19/09/2020 06:36, Frédéric Wang wrote: > This is already possible > with the MathML's displaystyle attribute but exposing the magic to CSS > provides more flexibility to users. As an example, consider the continued fraction of test 6 in https://mdn.mozillademos.org/en-US/docs/Mozilla/MathML_Project/MathML_Torture_Test$samples/MathML_Torture_Test in order to avoid that it behaves like test 7, a displaystyle="true" is attached on each element. Using a CSS selector to force math-style: normal; on all the mfrac descendants would be more convenient. -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to prototype: math-style property
Summary: Implements the math-style property which indicates whether MathML equations should render with normal or compact height (this is similar to TeX's \displaystyle concept). This is already possible with the MathML's displaystyle attribute but exposing the magic to CSS provides more flexibility to users. This is already implemented as an internal -moz-math-display property, so we essentially just need to rename and expose it. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1665975 Standard: * https://mathml-refresh.github.io/mathml-core/#the-math-style-property * https://github.com/w3c/csswg-drafts/issues/5387 Platform coverage: All Preference: layout.css.math-style.enabled Devtools bug: N/A: no extra work is required for devtools. Other browsers: * Safari: considering ( https://bugs.webkit.org/show_bug.cgi?id=216702 ), the MathML displaystyle inheritance was implemented via an internal structure (when WebKit didn't support internal CSS property), this can be easily rewritten by implementing the CSS math-style property. * Chrome: shipped behind the MathMLCore flag (patch landed in https://chromium-review.googlesource.com/c/chromium/src/+/2100787 ) but the values must be fixed to match the spec. web-platform-tests: - Existing tests use Chromium's values and must be fixed to match the spec. - Most of the effects are specific to MathML layout and tested by https://w3c-test.org/mathml/ (displaystyle mapping to math-style and effect of displaystyle on MathML layout) - Tentative CSS tests are available in https://w3c-test.org/css/css-fonts/math-script-level-and-math-style but the interaction with the math-level/font-size won't be testable until we expose -moz-script-level too. Secure contexts: Like all other CSS selectors these are not restricted to secure contexts. Is this feature enabled by default in sandboxed iframes?: Yes -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: MathML deprecated style, menclose@radical, mathsize/linethicknes named values, mfrac@bevelled, alignment attributes, script shift attributes, XLink.
Hi, As of september 24, I intend to disable the features below on all platforms. For details, please read the intent to deprecation threads linked below. We have sent deprecation warnings for them since last year. Emilio helped me to collect the data and the number of pings with such counters (collected on the release channel on data submitted from early-this-august) are litterally 0 or 1. As a comparison, the counter for pages using MathML is in the millions. mathml.deprecated_style_attributes.disabled https://groups.google.com/u/1/g/mozilla.dev.platform/c/kl5c87mBlO0/m/7b2SXbEEDwAJ mathml.deprecated_menclose_notation_radical.disabled https://groups.google.com/u/1/g/mozilla.dev.platform/c/vwAkuZIEhnY/m/KALRPR3wAQAJ mathml.mathsize_names.disabled https://groups.google.com/u/1/g/mozilla.dev.platform/c/kyB34PjYXek/m/M7CAmcmmDAAJ mathml.mfrac_bevelled_attribute.disabled https://groups.google.com/u/1/g/mozilla.dev.platform/c/9pEvlYn-Xyw/m/s7vpc2qeCgAJ mathml.deprecated_alignment_attributes.disabled https://groups.google.com/u/1/g/mozilla.dev.platform/c/JnJVGTmIwPE/m/xrido8-zAQAJ mathml.script_shift_attributes.disabled https://groups.google.com/u/1/g/mozilla.dev.platform/c/CAqw0Nxw6Pg/m/VzNdx_aaCgAJ mathml.xlink.disabled https://groups.google.com/u/1/g/mozilla.dev.platform/c/70NFnet82cU/m/4VOMUDfpDwAJ mathml.mfrac_linethickness_names.disabled https://groups.google.com/u/1/g/mozilla.dev.platform/c/G91-vBeC3Rw/m/irFYGNx0DAAJ -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: stretching MathML operators with STIXGeneral fonts on non-mac platform
Hi, As of September 24, I intend to disable support for stretching MathML operators with the deprecated STIXGeneral fonts on non-mac platform. These are very old fonts that have been deprecated by the STIX consortium for a long time and we have been encouraging users to switch to modern fonts since 2014. For details see http://groups.google.com/u/1/g/mozilla.dev.platform/c/ufT7Oc42MEc/m/xiOlQxIECQAJ The flag will stay enabled on macOS because the current release (Catalina) still has the STIXGeneral fonts pre-installed, and so users who didn't install math fonts would still get better MathML rendering when the flag is on. -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: stretching MathML operators with STIXGeneral fonts on non-mac platform
On 17/09/2020 15:22, Frédéric Wang wrote: > Hi, > >As of September 24, I intend to disable support for stretching MathML > operators with the deprecated STIXGeneral fonts on non-mac platform. > These are very old fonts that have been deprecated by the STIX > consortium for a long time and we have been encouraging users to switch > to modern fonts since 2014. For details see > http://groups.google.com/u/1/g/mozilla.dev.platform/c/ufT7Oc42MEc/m/xiOlQxIECQAJ > >The flag will stay enabled on macOS because the current release > (Catalina) still has the STIXGeneral fonts pre-installed, and so users > who didn't install math fonts would still get better MathML rendering > when the flag is on. > s/ship/unship/ in the title. -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: title argument of Navigator.registerProtocolHandler
On 21/04/2020 08:51, Frédéric Wang wrote: > As of 2020-05-05 I intend to remove the title argument of > Navigator.registerProtocolHandler. It has been removed from the HTML5 > specification and none of the existing implementation does something > UI-wise [1]. This change finally landed yesterday. -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to prototype & ship: Treat localhost addresses as "Potentially Trustworthy"
Hi, I'm going to try and land a patch for bug 1220810 today, which makes localhost addresses secure contexts. It seems there were attempts to land this change 7 months ago and again 3 months ago, but I can't find any intent email, so I'm sending this one. Summary: Ensure that localhost addresses resolve to a loopback address, thereby ensuring that we can safely treat `http://localhost/` and `http://*.localhost/` as "Potentially Trustworthy". This addresses various bug reports from developers and aligns with specifications. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1488740 Standards: https://w3c.github.io/webappsec-secure-contexts/#localhost https://tools.ietf.org/html/draft-west-let-localhost-be-localhost Platform coverage: All Preference: This will ship enabled by default (existing network.proxy.allow_hijacking_localhost preference can be used to disable the hardcoded loopback address and resolve proxy for localhost but I think it's mostly for internal testing). DevTools bug: N/A Other browsers: Chromium: Shipped since version 83 (https://bugs.chromium.org/p/chromium/issues/detail?id=589141#c15) WebKit: Considering (https://bugs.webkit.org/show_bug.cgi?id=171934#c73) web-platform-tests: This is covered by internal Gecko tests, but I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1672323 as a follow-up. -- Frédéric Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
