Intent to ship: Honoring bogo-XML declaration for character encoding in text/html

. On Wed, Mar 10, 2021 at 5:56 PM Henri Sivonen wrote: > > # Summary > > For compatibility with WebKit and Blink, honor the character encoding > declared using the XML declaration syntax in text/html. > > For reasons explained in https://hsivonen.fi/utf-8-detection/ , unlike &

Intent to prototype: Honoring bogo-XML declaration for character encoding in text/html

://hsivonen.com/test/moz/xml-decl/ contains tests which are wrapped for WPT as part of the Gecko patch. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: User-facing benefits from UA exposure of Android version and Linux CPU architecture

On Thu, Feb 18, 2021 at 11:26 PM Mike Hommey wrote: > > On Thu, Feb 18, 2021 at 01:51:07PM +0200, Henri Sivonen wrote: > > Does reporting "Linux aarch64" have significant concrete benefits to > > users? Would actual presently-existing app download pages break if

User-facing benefits from UA exposure of Android version and Linux CPU architecture

undo the change if we made mozilla-central say "Linux x86_64" regardless of the actual ISA on Linux? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: Exposure of 11.x macOS versions in the User-Agent string

and Chrome, as Firefox and Chrome advertise WebP via the Accept header and don't rely on the OS decoder. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Gecko performance with newer x86_64 levels

On Tue, Feb 9, 2021 at 5:35 PM Gian-Carlo Pascutto wrote: > > On 3/02/2021 10:51, Henri Sivonen wrote: > > I came across > > https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level/ > > . Previously, whe

Re: Intent to unship: FTP protocol implementation

advertising the capability to act as an ftp: URL handler to operating systems? Currently, if I try to follow an ftp: URL in Gnome Terminal, it tries to launch Firefox. Is that something we advertise to Gnome or something that Gnome just knows and needs to be patched to stop knowing? -- Henri S

Gecko performance with newer x86_64 levels

pick the right one and to use the new glibc-hwcaps mechanism on Linux? For macOS and Android, do we actively track the baseline CPU age that Firefox-compatible OS versions run on and adjust the compiler options accordingly when we drop compatibility for older OS versions? -- Henri Sivonen hsivo

Re: Status of Ubuntu 20.04 as a development platform

On Tue, Nov 10, 2020 at 4:39 PM James Graham wrote: > > On 10/11/2020 14:17, Kyle Huey wrote: > > On Tue, Nov 10, 2020 at 3:48 AM Henri Sivonen wrote: > >> > >> Does Ubuntu 20.04 work properly as a platform for Firefox development? > >> That is, does rr w

Re: Enabled CRLite in Nightly

." If the delta updates are averaging 66 KB, do we really need to avoid the updates over cellular data even when that's assumed to be metered? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https

Status of Ubuntu 20.04 as a development platform

Does Ubuntu 20.04 work properly as a platform for Firefox development? That is, does rr work with the provided kernel and do our tools work with the provided Python versions? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev

Re: Please don't use functions from ctype.h and strings.h

On Wed, Jun 24, 2020 at 10:35 PM Chris Peterson wrote: > > On 8/27/2018 7:00 AM, Henri Sivonen wrote: > > I think it's worthwhile to have a lint, but regexps are likely to have > > false positives, so using clang-tidy is probably better. > > > > A bug is on fil

Please don't use locale-dependent C standard library functions (was: Re: Please don't use functions from ctype.h and strings.h)

, Aug 27, 2018 at 3:04 PM Henri Sivonen wrote: > > Please don't use the functions from ctype.h and strings.h. > > See: > https://daniel.haxx.se/blog/2018/01/30/isalnum-is-not-my-friend/ > https://daniel.haxx.se/blog/2008/10/15/strcasecmp-in-turkish/ > https://stackoverflow.com/

Re: Proposal: remove support for running desktop Firefox in single-process mode (e10s disabled) anywhere but in tests

t; core a11y engine (vs the a11y e10s stuff). This is also relevant to other debugging scenarios, especially when not being able to use Pernosco to search for the right process. What does this proposal mean for ./mach run --disable-e10s ? -- Henri Sivonen hsivo...

Re: Intent to unship: FTP protocol implementation

ow why Chrome didn't proceed as planned? Do we know what their current plan is? Do we know if Edge intends to track Chrome on this feature or to make an effort to patch a different outcome? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list

Re: Intent to ship: Autodiscovery of WebExtension search engines

On Tue, Feb 25, 2020 at 10:04 PM Dale Harvey wrote: > Yes, extensions that only define a new search engine will be permitted, > the extension will not be able to do anything else. What capabilities do search engine-only WebExtensions have that OpenSearch doesn't provide? -- Henri S

Re: Intent to prototype: Character encoding detector

On Mon, Dec 2, 2019 at 2:42 PM Henri Sivonen wrote: > 1. On _unlabeled_ text/html and text/plain pages, autodetect _legacy_ > encoding, excluding UTF-8, for non-file: URLs and autodetect the > encoding, including UTF-8, for file: URLs. > > Elevator pitch: Chrome already did th

Re: Intent to prototype: Character encoding detector

On Thu, Dec 5, 2019 at 8:08 PM Boris Zbarsky wrote: > > On 12/2/19 7:42 AM, Henri Sivonen wrote: > > Since there isn't a spec and Safari doesn't implement the feature, > > there are no cross-vendor tests. > > Could .tentative tests be created here, on the off chance th

Intent to prototype: Character encoding detector

he feature for itself by using the UTF-8 BOM. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: C++ standards proposal for a embedding library

l URL scheme: It looks like the app-internal URL scheme is expected to map a URL to a stream of bytes as opposed to a Content-Type and a stream of bytes. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: C++ standards proposal for a embedding library

dy exist as "platform capabilities". -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Web Speech API

ad 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

Re: Intent to ship: Web Speech API

ly how this API works in Chrome, the audio is instead sent to a destination of Chrome's choosing and not to a destination of mdn.github.io's choosing. The example didn't work for me in Safari.) -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform m

Re: Passing UniquePtr by value is more expensive than by rref

https://rust.godbolt.org/z/SZQaAS ) which really makes one appreciate both Rust-style move semantics and the explicitly not-committal ABI. (I had to put a side-effectful println! in bar to make sure a call to bar is generated, since #[inline(never)] isn't enough to prevent the compiler from eliding ca

Re: Intent to ship: Web Speech API

processed in our cloud servers, not on device. What should one read to understand the issues that lead to this change? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Non-XPCOM in-RAM Unicode representation conversions have moved

encodings and streaming continues to be in mozilla/Encoding.h. Conversions where the target is an XPCOM string remain in nsReadableUtils.h. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.m

Re: Intent to unship: TLS 1.0 and TLS 1.1

On Fri, Sep 13, 2019 at 3:09 AM Martin Thomson wrote: > > On Thu, Sep 12, 2019 at 5:50 PM Henri Sivonen wrote: >> >> Do we know what the situation looks like for connections to RFC 1918 >> addresses? > > That's a hard one to even speculate about, and that's all

Re: Intent to unship: TLS 1.0 and TLS 1.1

0 and 1.1 for all people using the Release > channel of Firefox in March 2020. Exact plans for how and when this will > happen are not yet settled. What expectations are there for being able to remove the code from NSS? -- Henri Sivonen hsivo

Re: Proposed W3C Charter: Timed Text (TT) Working Group

or further development on TTML and WebVTT? (That is, what's currently missing such that these aren't considered "done"?) -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: JS testing functions and compartments in mochitest-plain

On Mon, Aug 26, 2019 at 1:37 PM Jan de Mooij wrote: > > On Mon, Aug 26, 2019 at 12:25 PM Henri Sivonen wrote: >> >> Thanks. Since SpecialPowers doesn't exist in xpcshell tests, is there >> another way to reach JS testing functions from there? > > > I think just

Re: JS testing functions and compartments in mochitest-plain

On Mon, Aug 26, 2019 at 11:27 AM Jan de Mooij wrote: > > On Mon, Aug 26, 2019 at 9:02 AM Henri Sivonen wrote: >> >> In what type of test does >> SpecialPowers.Cu.getJSTestingFunctions().newRope() actually return a >> rope within the calling compartment such that p

JS testing functions and compartments in mochitest-plain

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

Re: Structured bindings and minimum GCC & clang versions

builds updated, updating to c++17 has some of it's own quirks. Thanks. The dependencies indeed look tricky. :-( I take it that doing what Chromium does and shipping a statically linked symbol-swapped copy of libc++ instead of depending on the system C++ standard library would have its own set of issues.

Structured bindings and minimum GCC & clang versions

bindings and return by initializer list for tuples (either by making sure mozilla::Tuple support these or by migrating from mozilla::Tuple to std::tuple) and thereby get ergonomic multiple return values in C++? -- Henri Sivonen hsivo...@mozilla.com

Re: Removing --enable-shared-js [Was: Rust and --enable-shared-js]

ug.cgi?id=1573098 to change that. (The actual addition of non-Cranelift Rust code of interest to jsrust_shared hasn't landed yet.) -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Non-header-only headers shared between SpiderMonkey and the rest of Gecko

On Tue, Aug 6, 2019 at 8:54 PM Kris Maglione wrote: > > On Tue, Aug 06, 2019 at 10:56:55AM +0300, Henri Sivonen wrote: > > Do we have some #ifdef for excluding parts of mfbt/ when mfbt/ is being used > > in a non-SpiderMonkey/Gecko context? > > #ifdef MOZ_HAS_MOZGL

Re: Removing --enable-shared-js [Was: Rust and --enable-shared-js]

in jsapi.h, and my understanding from All Hands was that adding these things would be OK, since SpiderMonkey already depends on Rust. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Non-header-only headers shared between SpiderMonkey and the rest of Gecko

On Tue, Aug 6, 2019 at 10:15 AM Henri Sivonen wrote: > In general, it seems problematic to organize headers based on whether > they have associated .cpp or crate code. I'd expect developers to look > for stuff under mfbt/ instead of some place else, since developers > using the head

Re: Non-header-only headers shared between SpiderMonkey and the rest of Gecko

On Mon, Aug 5, 2019 at 4:14 PM Gabriele Svelto wrote: > On 05/08/19 12:04, Henri Sivonen wrote: > > I has come to my attention that that putting non-header-only code > > under mfbt/ is something we're trying to get away from: > > https://bugzilla.mozilla.org/show_bug.cgi?id=

Re: NotNull and pointer parameters that may or may not be null

the grounds that it was endorsed by the Core Guidelines.) -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Non-header-only headers shared between SpiderMonkey and the rest of Gecko

to ship Gecko-specific code via crates.io and Gecko developers probably aren't looking for mfbt type-aware C++ API headers under third_party/rust/.) -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

strings using uint32_t for _fields_, it seems to me that a significant part of our uint32_t (originally PRUint32, of course) habit comes from the days when Tru64 Unix was the main 64-bit Gecko platform, therefore, we lacked proper 64-bit testing coverage. --

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

o know why? Is this due to worries about underflow or > odd behavior on subtraction or something? I don't _know_, but most like they want to benefit from optimizations based on overflow being UB. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platfor

Re: Intent to unship:

ert enrollment path anymore, what concretely should be used instead? (To be clear: I'm not a fan of client certs, and I'm not requesting that there be an enrollment path.) -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platf

Re: Running C++ early in shutdown without an observer

On Fri, Jun 7, 2019 at 9:45 PM Chris Peterson wrote: > > On 6/7/2019 9:36 AM, Kris Maglione wrote: > > On Fri, Jun 07, 2019 at 09:18:38AM +0300, Henri Sivonen wrote: > >> For late shutdown cleanup, we have nsLayoutStatics::Shutdown(). Do we > >> have a similar met

Running C++ early in shutdown without an observer

that _it_ gets cleaned up properly.) -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Remove browser and OS architecture from Firefox's User-Agent string?

ites distributing windows executables might key off the > OS version to default to the correct exe for your version of windows? Are there known examples of apps like that? AFAICT, even Skype.com provides the Windows 7 -compatible .exe as the downloa

Re: Remove browser and OS architecture from Firefox's User-Agent string?

d=1169772 about exposing _some_ Android version number for Web compat says the reason not to make Firefox claim the same Android version for all users regardless of actual system version is that doing so would require bumping the version later: https://bugzilla.mozilla.org/show_bug.cgi?id=1169772#c36

Re: Personally opining that new C++ library facilities should not support non-UTF encodings

I sent this to SG16 (after tweaking it a bit to downplay UTF-16 and UTF-32). On Mon, Apr 22, 2019 at 1:19 PM Henri Sivonen wrote: > > (If you don't care about what I say about character encoding issues in > the context of C++ standardization outside my Mozilla activities, you > c

Personally opining that new C++ library facilities should not support non-UTF encodings

ute around.) -- 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: Intent to deprecate - linux32 tests starting with Firefox 69

's own positioning?) -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charters: Internationalization (i18n) Working Group and Interest Group

On Tue, Apr 9, 2019 at 11:13 PM L. David Baron wrote: > > On Tuesday 2019-04-09 13:55 +0300, Henri Sivonen wrote: > > On Mon, Apr 8, 2019 at 11:32 PM L. David Baron wrote: > > > > > > The W3C is proposing revised charters for: > > > > > > Interna

Re: Proposed W3C Charters: Internationalization (i18n) Working Group and Interest Group

ssues. I don't see a charter item that clearly covers the maintenance of this document. Should we ask for an item that ensures that the group is explicitly chartered to continue to maintain this document? -- Henri Sivonen hsivo...@mozilla.com _

Re: Proposed W3C Charter: Web & Networks Interest Group

so that things aren't visible to the network between the end points and the tendency to consider it unwanted for the network to take actions other than making the packets travel between the end points. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platf

Re: Intent to implement and experiment: Require user interaction for notification permission prompts

What's the current status of getting a cross-browser definition for something being invoked in response to a user gesture? Does scrolling count as a user gesture? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

here making the FIDO U2F API whitelist a pref. I can’t > say whether I would welcome adding more domains to it by default; I > think we’re going to have to take them on a case-by-case basis. What user-relevant problem is solved by having to add domains to a list

Re: Type-based alias analysis and Gecko C++

On Wed, Feb 27, 2019 at 10:20 AM Henri Sivonen wrote: > Given the replies to this thread and especially the one I quoted > above, I suggest appending the following paragraph after the first > paragraph of > https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_cod

Re: What is dom/browser-element/ used for?

I think I found a user in dev tools: https://searchfox.org/mozilla-central/rev/2a6f3dde00801374d3b2a704232de54a132af389/devtools/client/responsive.html/components/Browser.js#140 On Thu, Feb 28, 2019 at 11:45 AM Henri Sivonen wrote: > > It appears dom/browser-element/ was created fo

What is dom/browser-element/ used for?

It appears dom/browser-element/ was created for Gaia. Is it used for something still? WebExtensions perhaps? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev

Re: Type-based alias analysis and Gecko C++

e integers for which all bit patterns of their size are valid value. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Type-based alias analysis and Gecko C++

On Fri, Feb 22, 2019 at 1:00 AM Jeff Walden wrote: > > On 2/17/19 11:40 PM, Henri Sivonen wrote: > > Rust, which combines the > > perf benefits of -fstrict-aliasing with the understandability of > > -fno-strict-aliasing? > > This is not really true of Rust. Rus

Re: Type-based alias analysis and Gecko C++

On Fri, Feb 15, 2019 at 6:47 PM Ted Mielczarek wrote: > > On Fri, Feb 15, 2019, at 4:00 AM, Henri Sivonen wrote: > > How committed are we to -fno-strict-aliasing? > > FWIW, some work was done to investigate re-enabling strict aliasing a while > ago but it proved untenable

Type-based alias analysis and Gecko C++

is not a good use of time if we're committed to not having type-based alias analysis. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: SVG Working Group

On Wed, Jan 23, 2019 at 11:23 AM Cameron McCormack wrote: > > On Thu, Jan 10, 2019, at 12:38 AM, Henri Sivonen wrote: > > A (non-changed) part of the charter says under SVG2: "This > > specification updates SVG 1.1 to include HTML5-compatible parsing". Is > &

Re: Intent to ship: TextEncoder.encodeInto() - UTF-8 encode into caller-provided buffer

On Mon, Jan 14, 2019 at 4:45 PM Boris Zbarsky wrote: > On 1/14/19 4:28 AM, Henri Sivonen wrote: > > This is now an "intent to ship". The feature landed in the spec, in > > WPT and in Gecko (targeting 66 release). > > Where do other browsers stand on this feat

Intent to ship: TextEncoder.encodeInto() - UTF-8 encode into caller-provided buffer

This is now an "intent to ship". The feature landed in the spec, in WPT and in Gecko (targeting 66 release). On Mon, Dec 17, 2018 at 9:12 AM Henri Sivonen wrote: > > # Summary > > TextEncoder.encodeInto() adds encoding JavaScript strings into UTF-8 > into cal

Re: Proposed W3C Charter: SVG Working Group

server-side software cannot make proper security decisions on the assumption that their implementation of the HTML parsing algorithm from some point in time matches the behavior of browsers. ) -- Henri Sivonen hsivo...@mozilla.com ___ dev-platfo

Re: Rust code coverage

s inlined? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Pointer to the stack limit

mozilla-central/search?q=symbol:_ZN2js19CheckRecursionLimitEP9JSContext=false ) -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Pointer to the stack limit

and on Dalvik. (On ART, desktop Linux, and 64-bit platforms we can make the stack "large enough" anyway.) Use case: Implementing a dynamic recursion limit. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list de

Intent to implement: TextEncoder.encodeInto() - UTF-8 encode into caller-provided buffer

/14505 # Is this feature restricted to secure contexts? No. This is a new method on an interface that predates restricting features to secure contexts. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https

Re: Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

On Tue, Dec 11, 2018 at 10:08 AM Henri Sivonen wrote: > How about I change it to 5 MB on the assumption that that's still very > large relative to pre-UTF-8-era HTML and text file sizes? I changed the limit to 4 MB. -- Henri Sivonen hsivo...@mozil

Re: Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

oping the patch, I saw only resource: URLs showing up as file: URLs to the HTML parser, so only resource: URLs got a special check that fast-tracks them to UTF-8 instead of buffering for detection like normal file: URLs. > On Mon, Dec 10, 2018 at 11:28 PM Henri Sivonen wrote: > >

Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

# web-platform-tests As far as I'm aware, WPT doesn't cover file: URL behavior, and there isn't a proper spec for this. Hence, unit tests use mochitest-chrome. # Is this feature restricted to secure contexts? Restricted to file: URLs. -- Henri Sivonen hsivo...@mozilla.com _

Re: Checking if an nsIURI came from a resource: URL

On Fri, Dec 7, 2018 at 5:05 PM Dave Townsend wrote: > > This suggests that channel.originalURI should help: > https://searchfox.org/mozilla-central/source/netwerk/base/nsIChannel.idl#37 Indeed, getting both nsIURIs from the channel works. Thanks! -- Henri Sivonen hsivo...@mo

Re: Checking if an nsIURI came from a resource: URL

principal? I have a channel at a later point, so I could reverse the decision made from the nsIURI by looking at the channel before the initial decision is acted upon in a meaningful way. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing

Checking if an nsIURI came from a resource: URL

It appears that my the time resource: URLs reach the HTML parser, their scheme is reported as "file" (at least in debug builds). Is there a way to tell from an nsIURI that it was expanded from a resource: URL? -- Henri Sivonen hsivo...@m

Re: Rust and --enable-shared-js

On Mon, Sep 24, 2018 at 3:24 PM, Boris Zbarsky wrote: > On 9/24/18 4:04 AM, Henri Sivonen wrote: >> >> How important is --enable-shared-js? I gather its use case is making >> builds faster for SpiderMonkey developers. > > > My use case for it is to be able to use the

Rust and --enable-shared-js

scale. Maybe #2 becomes feasible before scaling up #1 becomes a problem. But still, I'm curious: How important is --enable-shared-js? I gather its use case is making builds faster for SpiderMonkey developers. Is that the only use case? Is it being used that way in practice? -- Henri Sivonen hsivo

Re: Extending the length of an XPCOM string when writing to it via a raw pointer

On Fri, Aug 31, 2018 at 8:43 AM, Henri Sivonen wrote: > At this point, it's probably relevant to mention that SetCapacity() in > situations other that ahead of a sequence of Append()s is most likely > wrong (and has been so since at least 2004; I didn't bother doing code > archeology

Re: Extending the length of an XPCOM string when writing to it via a raw pointer

On Thu, Aug 30, 2018 at 7:43 PM, Henri Sivonen wrote: >> What is then the point of SetCapacity anymore? > > To avoid multiple allocations during a sequence of Append()s. (This is > documented on the header.) At this point, it's probably relevant to mention that SetCapacity() in s

Re: Extending the length of an XPCOM string when writing to it via a raw pointer

On Thu, Aug 30, 2018 at 6:00 PM, smaug wrote: > On 08/30/2018 11:21 AM, Henri Sivonen wrote: >> >> We have the following that a pattern in our code base: >> >> 1) SetCapacity(newCapacity) is called on an XPCOM string. >> 2) A pointer obtained from BeginW

Extending the length of an XPCOM string when writing to it via a raw pointer

d like to remove it as redundant, so please don't use GetMutableData(). -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Dead-code removal of unused Rust FFI exports

t; equivalent to -fvisibility=hidden for Rust for that to stop being true. Exporting Rust FFI symbols from libxul seems bad not just for binary size but also in terms of giving contact surface to invasive third-party Windows software. Do we have a bug on file tracking the hiding of FFI symbols from th

Dead-code removal of unused Rust FFI exports

Does some lld mechanism successfully remove dead code when gkrust exports some FFI function that the rest of Gecko never ends up calling? I.e. in terms of code size, is it OK to vendor an FFI-exposing Rust crate where not every FFI function is used (at least right away)? -- Henri Sivonen hsivo

Re: Please don't use functions from ctype.h and strings.h

mingw-capitalization.yml > https://searchfox.org/mozilla-central/source/tools/lint/cpp/mingw-capitalization.py > > -tom > > On Mon, Aug 27, 2018 at 7:04 AM, Henri Sivonen wrote: >> >> Please don't use the functions from ctype.h and strings.h. >> >> See: >

Please don't use functions from ctype.h and strings.h

nsUnicharUtils.h For strcasecmp() and strncasecmp(), please use their nsCRT::-prefixed versions from nsCRT.h. (Ideally, we should scrub these from vendored C code, too, since being in third-party code doesn't really make the above problems go away.) -- Henri Sivonen hsivo...@mozilla.com

Changes in XPCOM string encoding conversions

e in order to make the use of C-style string hard, though, but in order to avoid clang complaining about ambiguous overloads.) -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/li

Re: Rust crate approval

rally on the topic of UTF-16 conversions in m-c Rust code.) -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Update on rustc/clang goodness

On Wed, May 30, 2018 at 5:16 PM, Mike Hommey wrote: > On Wed, May 30, 2018 at 02:40:01PM +0300, Henri Sivonen wrote: >> The Linux distro case is >> trickier than Mozilla's compiler choice. For CPUs that are tier-3 for >> Mozilla, we already tolerate less great performance a

Re: Update on rustc/clang goodness

c on LLVM than on GCC and now that technical design leads to better synergy with clang. -- 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: License of test data?

OTICE file) involve editing https://searchfox.org/mozilla-central/source/toolkit/content/license.html , too. -- 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: Proposed W3C Charter: JSON-LD Working Group

On Sun, Apr 29, 2018, 19:35 L. David Baron wrote: > OK, here's a draft of an explicit abtension that I can submit later > today. Does this seem reasonable? > This looks good to me. Thank you. > > One concern that we've had over the past few years about JSON-LD > is that

Re: Proposed W3C Charter: JSON-LD Working Group

eviously: serving XHTML as text/html while pretending to get benefits of the XML processing model that way). -- 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: Default Rust optimization level decreased from 2 to 1

takenly thought that cargo's "release" mode meant the same thing as Firefox "release" mode. I only later learned that I had developed with opt-level=3 (cargo's default for "release") and we ship with opt-level=2. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ __

Re: Intent To Require Manifests For Vendored Code In mozilla-central

script to enforce that bogus values don't creep in. -- 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: Is realloc() between bucket sizes worthwhile with jemalloc?

e realloc is large > enough, this is probably more efficient than memcpy. Thanks. Being able to avoid useless copying for most strings probably outweighs the loss of the pages_copy optimization for huge strings on Mac. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ __

Re: Editing a vendored crate for a try push

On Mon, Apr 9, 2018 at 10:32 PM, <twisniew...@mozilla.com> wrote: > On Monday, April 9, 2018 at 11:39:35 AM UTC-4, Henri Sivonen wrote: >> How do I waive .cargo-checksum.json checking for a crate? > > In bug 1449613 (part 12) I just hand-edited the .cargo-checksum.json in &g

Is realloc() between bucket sizes worthwhile with jemalloc?

lessly use realloc to copy data that's not semantically live data from the string's point of view and wouldn't really need to be preserved. Have I actually discovered useless copying or am I misunderstanding? -- Henri Sivonen hsivo...@hsivonen.fi https://h

Editing a vendored crate for a try push

-checksum.json checking for a crate? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

  1   2   3   4   5   >