Re: Intent to prototype: Web Speech API

[Andre Natal]

I changed the subject of this thread to fit properly the current intent.

We also moved the FAQ from Gdocs to mozilla wiki [1] with more current and
updated info. I've also added more content about offline recognition and
how to use deep speech to the ones interested about it.

Let's just use the wiki as the main source of info about this work.

Thanks

Andre

[1] https://wiki.mozilla.org/Web_Speech_API_-_Speech_Recognition

On Mon, Oct 14, 2019 at 4:20 PM Andre Natal  wrote:

>
> Hi Henri,
>
> the API isn't available in Nightly yet since the code wasn't fully
> reviewed neither merged yet. You can follow its progress here [1] and here
> [2]. If you want to try it before it's merged, just apply the patch [2] to
> an updated gecko-dev branch, switch on the *media.**webspeech.*
> *recognition.**enable *and *media.**webspeech.**recognition.**force_enable
> *flags, and browse to that page again.
>
> 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]), but in our case the
> audio will be sent to the endpoint set in the 
> *media.webspeech.service.endpoint
> *pref, which the user will be allowed to change (differently than
> Chrome). But if that's unset, it will send it to Mozilla's own server which
> is defaulted to in the code.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1248897#c18
> [2] https://phabricator.services.mozilla.com/D26047
> [3]
> [image: Screenshot 2019-10-14 16.13.49.png]
>
> On Mon, Oct 14, 2019 at 1:39 AM Henri Sivonen 
> wrote:
>
>> On Sat, Oct 12, 2019 at 12:29 PM Andre Natal  wrote:
>> > We tried to capture everything here [1], so please if you don't see your
>> > question addressed in this document, just give us a shout either here in
>> > the thread or directly.
>> ...
>> > [1]
>> >
>> https://docs.google.com/document/d/1BE90kgbwE37fWoQ8vqnsQ3YMiJCKJSvqQwa463yCN1Y/edit?ts=5da0f63f#
>>
>> Thanks. It doesn't address the question of what the UI in Firefox is
>> like. Following the links for experimenting with the UI on one's own
>> leads to https://mdn.github.io/web-speech-api/speech-color-changer/ ,
>> which doesn't work in Nightly even with prefs flipped.
>>
>> (Trying that example in Chrome shows that Chrome presents the
>> permission prompt as a matter of sharing the microphone with
>> mdn.github.io as if this was WebRTC, which suggests that mdn.github.io
>> decides where the audio goes. Chrome does not surface that, if I
>> understand correctly 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
>>
>
>
> --
>
> --
> Thanks,
>
> Andre
>


-- 

-- 
Thanks,

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

Of writing asynchronous tests

[smaug]

Hi all,

during the past year, while optimizing page load by changing how various tasks 
within Gecko are scheduled,
intermittently failing tests have often caused trouble and required fixes to 
them or occasionally
disabling them. Now with Fission we are seeing even more issues and we will do 
page load optimizations on top of
Fission, and that will probably reveal yet more issues.

A somewhat old page 
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Avoiding_intermittent_oranges
 has still a pretty good list
of common pitfalls. I recommend everyone writing asynchronous tests to take a 
look at that
(and possibly add more cases there, if you think the page is missing something).

This is not to blame anyone - writing asynchronous tests can be hard. I 
certainly have been fixing recently tests written by myself ;)
But I'm hoping that we can improve the quality of the tests over the time and 
thus make it easier to make changes to Gecko's
task and/or process scheduling.


Thanks,



-Olli

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

Re: [blink-dev] Re: What to do about scroll anchoring?

[Rick Byers]

Sorry for the delay.

We agree that scroll anchoring has unrealized potential to be valuable for
the web at large, and to make that happen we should be investing a lot more
working with y'all (and if we can't succeed, probably removing it from
chromium). Concretely +Chris Harrelson who leads rendering for Chrome (and
likely someone else from his team), as well as +Nick Burris from the Chrome
input team will start digging in ASAP. In addition to just the normal
high-bandwidth engineer-to-engineer collaboration between chromium and
gecko I propose the following high-level goals for our work:

   - Ensure that there are no known deviations in behavior between chromium
   and the spec (one way or the other).
   - Ensure all the (non-ua-specific) site compat constraints folks are
   hitting are captured in web-platform-tests. I.e. if Gecko passes the tests
   and serves a chromium UA string it should work as well as in Chrome (modulo
   other unrelated UA compat issues of course).
   - Look for any reasonable opportunity to help deal with UA-specific
   compat issues (i.e. those that show up on sites that are explicitly looking
   for a Gecko UA string or other engine-specific feature). This may include
   making changes in the spec / chromium implementation. This is probably the
   toughest one, but I'm optimistic that if we nail the first two, we can find
   some reasonable tradeoff for the hard parts that are left here. Philip (our
   overall interop lead) has volunteered to help out here as well.

Does that sound about right? Any suggestions on the best forum for tight
engineering collaboration? GitHub good enough, or maybe get on an IRC /
slack channel together somewhere?

Rick

On Mon, Oct 7, 2019 at 2:11 PM Mike Taylor  wrote:

> Hi Rick,
>
> On 9/28/19 10:07 PM, Rick Byers wrote:
> > Can you give us a week or so to chat about this within the Chrome team
> > and get back to you?
>
> Any updates here?
>
> Thanks.
>
> --
> Mike Taylor
> Web Compat, Mozilla
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [blink-dev] Re: What to do about scroll anchoring?

[Chris Harrelson]

On Sun, Sep 29, 2019 at 2:24 PM Emilio Cobos Álvarez 
wrote:

>  pretty significant behavior differences were only
> caught later by me and people finding compat issues in the wild, like
> [3]. I was sad that the spec reflected absolutely nothing like what
> Blink implements. For this issue in particular, Blink roughly uses
> "whatever inherits from LayoutBox can be an anchor", which is obviously
> not something that you can reasonably spec, and definitely not "block
> boxes and text", which is what the spec said.
>

Quick note: this one can be spec'ed. The classes that inherit from
LayoutBox all map directly to spec concepts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [blink-dev] Re: What to do about scroll anchoring?

[Rick Byers]

On Fri, Sep 27, 2019 at 10:16 AM Emilio Cobos Álvarez 
wrote:

> Hi Steve,
>
> On 9/27/19 4:03 PM, Steve Kobes wrote:
> > Hi Emilio,
> >
> > My recollection is that scroll anchoring was, in fact, a mess.  I do not
> > personally have any opinion about whether scroll anchoring should be
> > removed from Gecko.
> >
> > We (Chrome) decided to accept some compat issues for the sake of
> > launching the feature.  This was a judgment call and could reasonably
> > have gone the other way.
>
> Right, my concern is that taking compat fallout with Chrome's market
> share may be acceptable, because people will likely fix their websites
> if they misbehave.
>
> But web developers may not take the same time to fix their site if it's
> broken on Firefox for Android, for example, which in turn drives Firefox
> users away (and you know this is a vicious cycle, the less users you
> have, the less people will care about fixing their websites in your
> browser).
>
> That being said, more generally, I care about being interoperable /
> predictable here for web developers, and seems like that ship may have
> sailed if we need to fix some Gecko-specific issues by tweaking our
> heuristics, but Chromium / Blink doesn't change them in the same way
> (which is understandable, I guess, though I've filed spec issues for our
> reasoning behind these changes, which I think would apply to Chrome as
> well).
>

FWIW, I agree with this principle. I'm sorry you've had to do a lot of
compat work on this Emilio. Are you saying you've found many cases where
chromium's behavior doesn't match the spec / web-platform-tests and the
different is relevant to real-world website compat (forcing you to invest
in "bug-for-bug compatibility")? That would definitely make me very sad. Or
is the issue more about compat with sites which have UA-conditional
behavior (either explicit or implicit based on some other Gecko/blink
difference?).

IMHO In general, either an initially chromium-only feature is valuable
enough that we should continue to invest as necessary to achieve interop
with other engines when they implement (eg. adding web-platform-tests and
improving the spec for the inevitable cases that appear with a second
implementation), or we should decide the feature isn't worth the cost to
properly support on the web at large and remove it from chromium.

Steve is the expert and can probably elaborate on details, but IIRC the
real world web compat constraints of scroll anchoring ended up requiring a
number of tough tradeoffs. If you're learning about new web compat
constraints, then it's entirely possible that the cost/benefit equation is
now different and we should be re-evaluating whether it still makes sense
to keep scroll anchoring in chromium. Like David I like the feature - but
only to the extent that it works alright for most of the web as it exists
today, and developers can reliably reason about it (eg. by replacing any
heuristics designed under the constraints of web-compat with explicit APIs).

Can you give us a week or so to chat about this within the Chrome team and
get back to you?

Thanks, and sorry again for the frustration. When we ship a feature first
in chromium, it's always our intent that subsequent compatible
implementations should be MUCH easier to ship (it's one of the main reasons
we invest so much in web-platform-tests).

  -- Emilio
>
> > On Fri, 27 Sep 2019 at 09:09, Emilio Cobos Álvarez  > > wrote:
> >
> > And, to be clear, we _can_ fix these compat issues, some way or
> another.
> >
> > One thought is to limit the amount of scroll adjustments without user
> > scrolling or stuff like that, which would prevent the "you get stuck
> on
> > the page".
> >
> > Making anchoring opt-in rather than opt-out is another option, but
> that
> > defeats most of the purpose of the feature, I guess.
> >
> > See also some of the Chromium docs on the compat issues they found[1]
> > and how were they trying to fix them before adding the
> > "layout-affecting-property changed" heuristic, which is what is on
> the
> > spec right now and what they implement.
> >
> > I just think that these are very hacky heuristics that are just
> > going to
> > bring a lot of compat pain and developer confusion.
> >
> > It doesn't help that all these things can break or not depending on
> the
> > speed at which the user scrolls, the amount of scroll events that the
> > user dispatches, the timing of these events relative to other
> > events, etc...
> >
> >-- Emilio
> >
> > [1]:
> >
> https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3NlVxE/edit
> > <
> https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3NlVxE/edit
> >
> >
> > On 9/27/19 2:23 PM, Emilio Cobos Álvarez wrote:
> >  > Hi,
> >  >
> >  > (cc'ing webkit-dev@ and blink-dev@ in case they have feedback or
> >  > opinions, as WebKit 

Re: [blink-dev] What to do about scroll anchoring?

[Kenji Baheux via dev-platform]

Hi,

When we initially started, we did have a rough time but I haven't seen any
issue nor heard any negative feedback about it. As far as I can tell from
the metrics, it seems to save a lot of user frustration.

Iirc, we collected a bunch of cases where the feature behave erratically.
We had a form, an outreach, perhaps some url-keyed metrics and/or what-if
metrics, auto-disengaging thresholds (?) It was a long time ago, perhaps
Steve has a better memory than I.

Are these compat issues specific to Firefox, or do they also trigger weird
behaviors on Chrome? Do you have a sense of the size and convergence for
the problematic cases?

On Fri, Sep 27, 2019, 21:23 Emilio Cobos Álvarez  wrote:

> Hi,
>
> (cc'ing webkit-dev@ and blink-dev@ in case they have feedback or
> opinions, as WebKit is the only engine which does not implement scroll
> anchoring, though I don't know if they plan to, and Blink is the only
> other engine that does implement it. Please reply to dev-platform@
> though.)
>
> TLDR: Scroll anchoring is really a mess.
>
> I didn't do the initial implementation of the feature in Gecko, but I've
> done a ton of work over the last few months to fix compat issues in our
> implementation (see all the bugs blocking [1]).
>
> At this point, our implementation is mostly compatible with Blink, but
> even with a bug-for-bug compatible implementation, we did get compat
> issues because of different content being served for different browsers,
> or because our anti-tracking protections changing the final content of
> the page slightly ([2] is an example of bug which only reproduces with
> ETP enabled only, but whose reduced test-case renders the site unusable
> in Chrome as well).
>
> If you hit one of the broken cases as a user you think the browser is
> completely broken, and the site is just unusable.
>
> I've fixed those by tweaking the heuristics Gecko uses. Those extra
> heuristics have also caused other compat issues, like [3], reported
> today, which will require other adjustments to the heuristics, etc...
>
> On top of that, the spec is not in a good state, with ton of open issues
> without feedback from the editors [4].
>
> So right now I'm at a stage where I think that the feature is just not
> worth it. It doesn't behave predictably enough for developers, and you
> have no guarantee of it behaving consistently unless you test a
> particular browser, with a particular content in a particular viewport
> size... That's not great given the current dominant position of
> Chromium-based browsers.
>
> On top, issues with scroll anchoring are pretty hard to diagnose unless
> you're aware of the feature.
>
> All in all, it doesn't seem like the kind of feature that benefits a
> diverse web (nor web developers for that matter), and I think we should
> remove the feature from Gecko.
>
> Does anyone have strong opinions against removing scroll anchoring from
> Gecko, based on the above?
>
> Thanks,
>
>   -- Emilio
>
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644
> [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450
> [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499
> [4]: https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/83f17f7c-6b68-b7dd-0761-239bd504e10e%40mozilla.com
> .
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [webkit-dev] What to do about scroll anchoring?

[Simon Fraser via dev-platform]

> On Sep 27, 2019, at 10:08 PM, Emilio Cobos Álvarez  wrote:
> 
> And, to be clear, we _can_ fix these compat issues, some way or another.
> 
> One thought is to limit the amount of scroll adjustments without user 
> scrolling or stuff like that, which would prevent the "you get stuck on the 
> page".
> 
> Making anchoring opt-in rather than opt-out is another option, but that 
> defeats most of the purpose of the feature, I guess.
> 
> See also some of the Chromium docs on the compat issues they found[1] and how 
> were they trying to fix them before adding the "layout-affecting-property 
> changed" heuristic, which is what is on the spec right now and what they 
> implement.
> 
> I just think that these are very hacky heuristics that are just going to 
> bring a lot of compat pain and developer confusion.
> 
> It doesn't help that all these things can break or not depending on the speed 
> at which the user scrolls, the amount of scroll events that the user 
> dispatches, the timing of these events relative to other events, etc…


I expressed my main issue with scroll anchoring at the F2F, which is that it’s 
an on-by-default behavior that is making up for bad web authoring, and is 
harmful if only implemented by a subset of browsers.

I would support removing it entirely, or having it be opt-in.

Simon

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

Re: [blink-dev] Re: What to do about scroll anchoring?

[Steve Kobes]

Hi Emilio,

My recollection is that scroll anchoring was, in fact, a mess.  I do not
personally have any opinion about whether scroll anchoring should be
removed from Gecko.

We (Chrome) decided to accept some compat issues for the sake of launching
the feature.  This was a judgment call and could reasonably have gone the
other way.

Steve

On Fri, 27 Sep 2019 at 09:09, Emilio Cobos Álvarez 
wrote:

> And, to be clear, we _can_ fix these compat issues, some way or another.
>
> One thought is to limit the amount of scroll adjustments without user
> scrolling or stuff like that, which would prevent the "you get stuck on
> the page".
>
> Making anchoring opt-in rather than opt-out is another option, but that
> defeats most of the purpose of the feature, I guess.
>
> See also some of the Chromium docs on the compat issues they found[1]
> and how were they trying to fix them before adding the
> "layout-affecting-property changed" heuristic, which is what is on the
> spec right now and what they implement.
>
> I just think that these are very hacky heuristics that are just going to
> bring a lot of compat pain and developer confusion.
>
> It doesn't help that all these things can break or not depending on the
> speed at which the user scrolls, the amount of scroll events that the
> user dispatches, the timing of these events relative to other events,
> etc...
>
>   -- Emilio
>
> [1]:
>
> https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3NlVxE/edit
>
> On 9/27/19 2:23 PM, Emilio Cobos Álvarez wrote:
> > Hi,
> >
> > (cc'ing webkit-dev@ and blink-dev@ in case they have feedback or
> > opinions, as WebKit is the only engine which does not implement scroll
> > anchoring, though I don't know if they plan to, and Blink is the only
> > other engine that does implement it. Please reply to dev-platform@
> though.)
> >
> > TLDR: Scroll anchoring is really a mess.
> >
> > I didn't do the initial implementation of the feature in Gecko, but I've
> > done a ton of work over the last few months to fix compat issues in our
> > implementation (see all the bugs blocking [1]).
> >
> > At this point, our implementation is mostly compatible with Blink, but
> > even with a bug-for-bug compatible implementation, we did get compat
> > issues because of different content being served for different browsers,
> > or because our anti-tracking protections changing the final content of
> > the page slightly ([2] is an example of bug which only reproduces with
> > ETP enabled only, but whose reduced test-case renders the site unusable
> > in Chrome as well).
> >
> > If you hit one of the broken cases as a user you think the browser is
> > completely broken, and the site is just unusable.
> >
> > I've fixed those by tweaking the heuristics Gecko uses. Those extra
> > heuristics have also caused other compat issues, like [3], reported
> > today, which will require other adjustments to the heuristics, etc...
> >
> > On top of that, the spec is not in a good state, with ton of open issues
> > without feedback from the editors [4].
> >
> > So right now I'm at a stage where I think that the feature is just not
> > worth it. It doesn't behave predictably enough for developers, and you
> > have no guarantee of it behaving consistently unless you test a
> > particular browser, with a particular content in a particular viewport
> > size... That's not great given the current dominant position of
> > Chromium-based browsers.
> >
> > On top, issues with scroll anchoring are pretty hard to diagnose unless
> > you're aware of the feature.
> >
> > All in all, it doesn't seem like the kind of feature that benefits a
> > diverse web (nor web developers for that matter), and I think we should
> > remove the feature from Gecko.
> >
> > Does anyone have strong opinions against removing scroll anchoring from
> > Gecko, based on the above?
> >
> > Thanks,
> >
> >   -- Emilio
> >
> > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644
> > [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450
> > [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499
> > [4]: https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4fb3b637-50f5-1167-62a0-dffdeff06f48%40mozilla.com
> .
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: String contenation and temporaries

[Boris Zbarsky]

On 10/16/19 10:11 AM, Simon Giesecke wrote:

I am wondering if the following is supposed to be safe:


I would think so, yes.  That said, using string types as return values 
is not that common (using an outparam is the normal way they are used), 
and so may be under-tested.



On the treeherder builds, this seems to work fine. But reportedly,
this crashes on a release build on Mac OS X 10.13 on startup. Static
analysis does not catch a problem here. Assigning the result of
MakeColumnPairSelectionList to an intermediate variable fixes the
issue there (https://phabricator.services.mozilla.com/D49422).


It's worth trying to pin down what's going on there on Mac (e.g. by 
looking at the generated assembly) to see whether it's our bug, a 
compiler bug, or something else...


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

Re: Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure

[lambanth71]

On Thursday, May 23, 2019 at 4:34:14 AM UTC-4, Andrea Marchesini wrote:
> Link to the proposal:
> https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
> 
> Summary:
>   "1.  Treat the lack of an explicit "SameSite" attribute as
>"SameSite=Lax".  That is, the "Set-Cookie" value "key=value" will
>produce a cookie equivalent to "key=value; SameSite=Lax".
>Cookies that require cross-site delivery can explicitly opt-into
>such behavior by asserting "SameSite=None" when creating a
>cookie.
>2.  Require the "Secure" attribute to be set for any cookie which
>asserts "SameSite=None" (similar conceptually to the behavior for
>the "__Secure-" prefix).  That is, the "Set-Cookie" value
>"key=value; SameSite=None; Secure" will be accepted, while
>"key=value; SameSite=None" will be rejected."
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1551798
> 
> Platform coverage: all
> 
> Estimated or target release: 69 - behind pref
> 
> Preferences behind which this will be implemented:
>  - network.cookie.sameSite.laxByDefault
>  - network.cookie.sameSite.noneRequiresSecure (this requires the previous
> one to be set to true)
> 
> Is this feature enabled by default in sandboxed iframes? yes.
> 
> Do other browser engines implement this?
>  - Chrome is implementing/experimenting this feature:
> https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
>  - Safari: no signal yet.
> 
> web-platform-tests: There is a pull-request
> https://github.com/web-platform-tests/wpt/pull/16957
> Implementing this feature, I added a mochitest to inspect cookies via
> CookieManager.
> 
> Is this feature restricted to secure contexts? no


-- 
This is a PVNC student account. Please report any abuse to 
helpd...@pvnccdsb.on.ca .

All
 student 
emails are scanned for objectionable content. A COPY of that 
email will be 
sent to the student’s school principal for review. 




*Achieving 
Excellence in Catholic Education through Learning, Leadership and Service*



Please visit our website at http://www.pvnccdsb.on.ca 
 or join us on social media:
Facebook: 
https://www.facebook.com/pvnccdsb 

Twitter: https://twitter.com/pvnccdsb 

Youtube: https://www.youtube.com/pvncc 



PVNCCDSB IMPORTANT NOTICE: This information is intended only for the use of 
the individual or entity to which it is addressed and may contain 
information that is privileged, confidential and exempt from disclosure 
under the Municipal Freedom of Information and Protection of Privacy Act. 
If the reader of this message is not the intended recipient or the employee 
or agent responsible for delivering the message to the intended recipient, 
you are hereby notified that any dissemination, distribution or copying of 
this communication is strictly prohibited. If you received this 
transmission in error, please notify the sender immediately and then 
permanently delete this 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

String contenation and temporaries

[Simon Giesecke]

Hi,

I am wondering if the following is supposed to be safe:

Given a function (from
https://searchfox.org/mozilla-central/source/dom/indexedDB/ActorsParent.cpp#9290):

nsAutoCString MakeColumnPairSelectionList(
const nsLiteralCString& aPlainColumnName,
const nsLiteralCString& aLocaleAwareColumnName,
const nsLiteralCString& aSortColumnAlias, const bool aIsLocaleAware) {
  return aPlainColumnName +
 (aIsLocaleAware ? EmptyCString()
 : NS_LITERAL_CSTRING(" as ") + aSortColumnAlias) +
 NS_LITERAL_CSTRING(", ") + aLocaleAwareColumnName +
 (aIsLocaleAware ? NS_LITERAL_CSTRING(" as ") + aSortColumnAlias
 : EmptyCString());
}

which is used here:

  const auto& indexTable = mCursor->mUniqueIndex
   ? NS_LITERAL_CSTRING("unique_index_data")
   : NS_LITERAL_CSTRING("index_data");

  NS_NAMED_LITERAL_CSTRING(sortColumn, "sort_column");

  const nsCString sortColumnAlias =
  NS_LITERAL_CSTRING("SELECT ") +
  MakeColumnPairSelectionList(
  NS_LITERAL_CSTRING("index_table.value"),
  NS_LITERAL_CSTRING("index_table.value_locale"), sortColumn,
  mCursor->IsLocaleAware()) +
  NS_LITERAL_CSTRING(", ");

  nsAutoCString queryStart = sortColumnAlias +
 NS_LITERAL_CSTRING("xxx") +
 indexTable +
 NS_LITERAL_CSTRING("xxx") +
 kStmtParamNameId;

Note that all strings that are concatenated here are either
nsLiteralCString or EmptyCString. I stripped down the actual literals
in the last statement for readability. While probably not everything
else is essential to the problem, but since I am not sure what might
be, I left the rest unchanged.

On the treeherder builds, this seems to work fine. But reportedly,
this crashes on a release build on Mac OS X 10.13 on startup. Static
analysis does not catch a problem here. Assigning the result of
MakeColumnPairSelectionList to an intermediate variable fixes the
issue there (https://phabricator.services.mozilla.com/D49422).

I am asking here, since this appears to be a general question on
correct use of the string classes. I read through the guide
(https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Guide/Internal_strings)
but I didn't find anything suspicious. I might have missed some point,
though.

Thanks a lot
Simon
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype: heading levels

[Anne van Kesteren]

Summary: The HTML Standard has for the longest time defined a feature
whereby you could exclusively use the h1 and sectioning elements, and
user agents would take care of adjusting the heading level according
to the nesting depth. Due to the complexity it never got adopted.
There’s an alternative proposal that amounts to counting sectioning
element ancestors for h1 elements only (and h2-h6 if their parent is
hgroup), which is much more doable performance-wise. That proposal
might see some further refinements for behavior around hgroup, based
on discussion in the issue linked below.
(https://annevankesteren.nl/2019/10/heading-levels goes into the
high-level idea a bit more.)

The idea is to ship this by default on Nightly and maybe Dev, but not
ride the trains (until the standard is more fully agreed and there's
an intent to ship).

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=998590.

Standard: https://github.com/whatwg/html/pull/3499 coupled with
https://github.com/whatwg/html/issues/5002.

Platform coverage: All.

Preference: accessibility.heading-element-level-changes.enabled.

DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1588784.

Other browsers: Have expressed mild interest to get to it eventually,
us having some code hopefully gets them more fully on board.

web-platform-tests: Unclear how to test heading levels, but once
there's a corresponding CSS pseudo-class to expose them there will be.

Secure contexts: No, bifurcating an existing HTML feature like that
doesn’t seem like a good idea.

Is this feature enabled by default in sandboxed iframes? Yes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Web Speech API

[Johann Hofmann]

Putting on my hat as one of the people maintaining our permissions UI, I
generally agree with Henri that it would be nice to have a slightly
different UI for this use-case, i.e. as far as I can see the presented
origin does not in fact get access to the user's microphone and it's a bit
unclear what "Remember this decision" actually does. It makes no sense to
set the "microphone" permission on that site, in the same way that it makes
no sense to derive from a permanent "microphone" permission for some site
that the user intends to submit their voice data to a third party. I feel
like this feature needs to store a separate permanent permission.

A perfect permissions UX may not be achievable or intended for an MVP of
this feature, so I would recommend at least hiding the checkbox (to avoid
setting the "microphone" permission) and prompting every time until a
better solution can be found.

Let me know if you need any help with that :)

Johann

On Tue, Oct 15, 2019 at 12:27 PM Henri Sivonen  wrote:

> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

nsIPermissionManager Permission Isolation by OriginAttributes

[Paul Zühlcke]

Hi everyone,

I plan to land a patch next week which will disable OriginAttribute
stripping in the permission manager. This will result in private browsing
windows and containers having isolated permissions. For example, if you
allow a website to send notifications in a normal window, this permission
will not be shared with private windows on the same website.
The patch will be enabled in Nightly and early Beta for now and can be
controlled using these prefs:

- permissions.isolateBy.privateBrowsing
- permissions.isolateBy.userContext

If you want to check or set permissions independently of private browsing
or user context make sure to strip the OriginAttributes from the principal
before calling the permission manager.

See Bug 1422056  for
more information.

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

Re: Range-based for and STL-style iterators for nsClassHashtable, nsDataHashtable, nsInterfaceHashtable

[mike . toom]

Op woensdag 2 oktober 2019 12:15:36 UTC+2 schreef Simon Giesecke:
> Hi,
> 
> I recently [1] added STL-style iterators and begin/cbegin/end/cend
> member functions to nsBaseHashtable. This means that it is now
> possible to use range-based for and STL algorithms operating on
> iterators with all of its subclasses, which include nsClassHashtable,
> nsDataHashtable, nsInterfaceHashtable, nsJSThingHashtable and
> nsRefPtrHashtable.
> 
> I also added an overview on existing support for range-based for and
> STL-style iterators in Mozilla data structures on MDN  at [2].
> 
> If you have any questions or issues, please let me know or NI me on Bugzilla.
> 
> Best wishes
> Simon
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1575479
> [2] 
> https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code#Mozilla_data_structures_and_standard_C_ranges_and_iterators

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