The problem is these were never a null string, they're a voided empty string. If you do a `str.get()` it gives you a valid pointer, not nullptr. Regardless, while this was primarily a string change, we probably should have pinged a dom peer; I had forgotten the weirdness that is DOMString [1]. Arguably that API should be taking a maybe param and arguably we should get rid of the void concept but that's not straightforward.
As a workaround for readability I think it would be reasonable to add some sort of `using NullString = VoidString` to DOMString.h. -e [1] http://searchfox.org/mozilla-central/rev/15ce5cb2db0c85abbabe39a962b0e697c9ef098f/dom/bindings/DOMString.h#153-173 On Fri, Sep 22, 2017 at 6:02 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 9/22/17 2:41 AM, Nicholas Nethercote wrote: > >> This probably won't affect most people, because void strings are a niche >> feature. >> > > Not in the DOM. They're used anytime you see "DOMString?" in webidl. > http://searchfox.org/mozilla-central/search?q=DOMString%3F&path=webidl > shows several hundred hits. > > Looking at the diff from bug 1401813, it looks like some of the uses are > in fact using the XPCOM "void string" feature per se, while some are > conceptually trying to represent "JS null" (e.g. in nullable string types > about to be passed to JS) and for those having a concept of null string, in > the sense defined by dom/base/nsDOMString.h, makes sense. > > Put another way, in the new setup the element lifecycle callbacks code in > Element::SetAttrAndNotify/UnsetAttr is much more confusing than it used > to be... > > -Boris > > _______________________________________________ > 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
