Re: MinGW Target on TaskCluster

[Ryan VanderMeulen]

On 2/6/2018 6:36 PM, Aaron Klotz wrote:

Furthermore, can we clarify whether mingw is currently a tier 1 or tier 2
platform? Earlier in this thread, mingw was denoted as tier 2 (and it still
shows up as tier 2 on treeherder), yet sheriffs are backing out patches
when mingw bustage occurs. Tor is important, so of course we want to make
our best effort to ensure that mingw isn't broken, but this "tier 2 but
really tier 1" state is not helpful.


Tier 2 job bustage shouldn't lead to an automatic backout under normal 
circumstances. Normal practice would be to file a bug for the bustage 
with a NI directed to the author of the patch that caused it. If you've 
been backed out without any such notice, feel free to raise your 
concerns directly with either myself or Sebastian.


Note that the sheriffing team does reserve the right to backout a patch 
for Tier 2 bustage if it's not addressed in a reasonable time frame 
(Tier 2 != unowned), but that would typically only happen in the 
situation where a bug Was filed and saw no further activity afterwards.


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

Re: MinGW Target on TaskCluster

[Tom Ritter]

Yes, let's fix it.

I'm very grateful to you and everyone else who has kept the MinGW
build running; and I'd like to keep you... well as happy as you can be
while supporting an esoteric build target that's inconvenient for you.

With regards to backouts, when sheriffs have asked, my response has
been that if something is directly attributable to a patch and it
doesn't look like it's a MinGW problem (like the recent missing
dwrite_3.h issue) - I'd appreciate a backout. This is mostly
selfishness, the times there was no backout and MinGW starts
perma-failing it's been up to me to diagnose the issue and fix it;
only once have MinGW patches been needed. If that needs to change,
alright.


As far as what we can do to make it easier. I think/hope MinGW isn't a
strain on TC; there are no tests associated, it even skips the normal
check-tests that run for other build jobs; and it runs on a small
Linux box so it should be the cheapest option for us. It could build
faster though; sccache doesn't work for it and I haven't been able to
figure out why (Bug 1411212).

> But when it comes to the header case mismatch issue, we could automate this.
> Would it be possible for us to write some code to automatically detect these 
> case
> discrepancies and automatically land corrections? Where would be the right 
> place
> for something like that to live?

I'd be happy to build something that does this. I don't know what's
possible or where it should live though. It's probably easy for me to
add it to the lint job, wherever that is.  I might be able to
integrate it into the new MozReview Static Analysis thing. I don't
know if it's possible, or how, to automatically land corrections* but
maybe?



Also, not that this is a solution for today but as I mentioned in the
first email - my hope is that some of this becomes easier with a move
to clang. It won't address everything, but I hope at least some of the
MinGW pain is lessened by a mingw-clang option. I could see us
patching our mingw-clang build to work with case insensitive includes
for example; and the __try/__except issues we have would go away also.
There's a few paths forward on this front. One using a mingw-clang,
one using clang-cl on Linux. The work on the first one is happening in
Bug 1390583.

-tom

* and I am nervous about giving some new system the ability to
automatically land code

On Tue, Feb 6, 2018 at 5:36 PM, Aaron Klotz  wrote:
> I'd like to follow up on this old thread to discuss what we can do about
> improving the mingw developer experience for people doing Windows-centric
> stuff.
>
> I've had several patches backed out over the past month because of mingw
> header files differing in case from the headers distributed by the official
> Windows SDK. Frankly, it's a waste of developer time to be dealing with
> this. This is particularly frustrating in the case of autoland, where we
> can't just push our own follow-up patches.
>
> Those of us who are trying to do Windows-specific stuff are effectively
> stuck simultaneously coding to two similar, yet still different, SDKs, being
> built across two distinct operating systems that differ in case sensitivity.
>
> In some cases, discrepancies between the SDKs are inevitable: Perhaps mingw
> hasn't kept up with the official Windows SDK and some headers/APIs are
> missing. We just have to take those as they come.
>
> But when it comes to the header case mismatch issue, we could automate this.
> Would it be possible for us to write some code to automatically detect these
> case discrepancies and automatically land corrections? Where would be the
> right place for something like that to live?
>
> Those of us locally building on Windows already have enough annoyances with
> the build as-is, so I don't consider "you should be building locally on both
> Windows/MSVC and Linux/mingw simultaneously" to be a reasonable option. Nor
> do I consider always pushing mingw jobs to try to be ideal: it delays the
> landing of patches and potentially wastes build machine time, compared to an
> automated lint.
>
> Furthermore, can we clarify whether mingw is currently a tier 1 or tier 2
> platform? Earlier in this thread, mingw was denoted as tier 2 (and it still
> shows up as tier 2 on treeherder), yet sheriffs are backing out patches when
> mingw bustage occurs. Tor is important, so of course we want to make our
> best effort to ensure that mingw isn't broken, but this "tier 2 but really
> tier 1" state is not helpful.
>
> I apologize for being curt, but this is becoming rather frustrating.
>
> Aaron
>
>
> On Mon, Oct 9, 2017 at 10:14 AM, Tom Ritter  wrote:
>>
>> On Mon, Oct 9, 2017 at 10:31 AM, Philipp Wagner 
>> wrote:
>>
>> > Am 09.10.2017 um 07:31 schrieb Tom Ritter:
>> > > As part of our work with Tor, we’ve been working on getting a
>> > > MinGW-based
>> > > build of Windows into TaskCluster.
>> >
>> > A maybe too obvious question from the side lines: Why is 

Most definitions of Ci, Cr, Cc, and Cu have been removed from the tree

[Andrew McCreight]

 Following up on my previous post, I have just landed (in bug 1432992) the
removal of most of the definitions of Ci, Cr, Cc, and Cu. This touched
almost 2000 files, so it may affect your patches, but hopefully rebasing is
easy. Thank you to Florian for reviewing a nearly-unreviewable patch and
suggesting a number of improvements, and to Raul and Aryx for shepherding
the patch's landing.

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

Re: MinGW Target on TaskCluster

[Aaron Klotz]

I'd like to follow up on this old thread to discuss what we can do about
improving the mingw developer experience for people doing Windows-centric
stuff.

I've had several patches backed out over the past month because of mingw
header files differing in case from the headers distributed by the official
Windows SDK. Frankly, it's a waste of developer time to be dealing with
this. This is particularly frustrating in the case of autoland, where we
can't just push our own follow-up patches.

Those of us who are trying to do Windows-specific stuff are effectively
stuck simultaneously coding to two similar, yet still different, SDKs,
being built across two distinct operating systems that differ in case
sensitivity.

In some cases, discrepancies between the SDKs are inevitable: Perhaps mingw
hasn't kept up with the official Windows SDK and some headers/APIs are
missing. We just have to take those as they come.

But when it comes to the header case mismatch issue, we could automate
this. Would it be possible for us to write some code to automatically
detect these case discrepancies and automatically land corrections? Where
would be the right place for something like that to live?

Those of us locally building on Windows already have enough annoyances with
the build as-is, so I don't consider "you should be building locally on
both Windows/MSVC and Linux/mingw simultaneously" to be a reasonable
option. Nor do I consider always pushing mingw jobs to try to be ideal: it
delays the landing of patches and potentially wastes build machine time,
compared to an automated lint.

Furthermore, can we clarify whether mingw is currently a tier 1 or tier 2
platform? Earlier in this thread, mingw was denoted as tier 2 (and it still
shows up as tier 2 on treeherder), yet sheriffs are backing out patches
when mingw bustage occurs. Tor is important, so of course we want to make
our best effort to ensure that mingw isn't broken, but this "tier 2 but
really tier 1" state is not helpful.

I apologize for being curt, but this is becoming rather frustrating.

Aaron


On Mon, Oct 9, 2017 at 10:14 AM, Tom Ritter  wrote:

> On Mon, Oct 9, 2017 at 10:31 AM, Philipp Wagner 
> wrote:
>
> > Am 09.10.2017 um 07:31 schrieb Tom Ritter:
> > > As part of our work with Tor, we’ve been working on getting a
> MinGW-based
> > > build of Windows into TaskCluster.
> >
> > A maybe too obvious question from the side lines: Why is the Tor browser
> > cross-compiled and not using MSVC?
> >
> >
> Building on Linux allows Tor Browser (including its entire toolchain and
> dependencies) to be built deterministically and thus reproducibly using an
> entirely open source toolchain. (There are a few small exceptions but
> they're quite small.)
>
> Reproducible builds significantly reduce the trust inherent in an
> organization's build infrastructure and when recreated independently ensure
> that nothing unexpected was inserted into the final executable. Having the
> entire toolchain open source ensures that anyone who wants to inspect the
> code or reason about its behavior can do so. (And as I've learned in the
> past year Tor actually has a good amount of anonymous contributors reading
> the source code of its toolchain and reporting things.)
>
> You can read more about the philosophy behind this movement at
> https://blog.torproject.org/deterministic-builds-part-one-
> cyberwar-and-global-compromise
> https://reproducible-builds.org/
> CCleaner is a good example of attackers backdooring compiled software.
>
> The next step, past reproducible builds, is Binary Transparency, which
> ensures that before an update is applied, it is publicly known, so
> attackers cannot surreptitiously subvert the update mechanism.  Tor is
> exploring some avenues there. FLAME is a good example of attacking the
> update mechanism.
>
> I would describe Mozilla as 'curious' about reproducible builds (see
> https://bugzilla.mozilla.org/show_bug.cgi?id=885777); but we are actively
> working on Binary Transparency (see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1341395).
>
> -tom
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship navigator.webdriver

[Andreas Tolfsen]

Also sprach Martin Thomson:

> On Tue, Feb 6, 2018 at 3:37 AM, Andreas Tolfsen  wrote:
>> Motivation:
>> To give web authors a way to infer if user agent is controlled by
>> automation, so the document can take alternate code paths when under
>> test.
> 
> Can you speak more about why this is a good idea?  I've poor
> experience with "this code is now under test" in the past.  You
> create the risk that code becomes split into two: code that works
> as tested, and code that doesn't work because it isn't tested.
> 
> (Not an objection, there's definitely value in consistency between
> implementations.)

As far as I’m aware the interface was added to the spec at the
explicit request of web authors.

I share your concern of code that gets written for “test only”
environments and that later fails to work in reality.  Another
aspect is that it is also important for test environments to induce
reproducibility.

One part to mitigating instability in tests is to eliminate sources
of indeterministic variance.  For example it might be reasonable
to want to replace Math.random with a PRNG with a fixed seed during
testing.

The most important characteristic of navigator.webdriver is that
it provides consistency.  With navigator.webdriver there’s _one
way_ to indicate to a document that it is under test, and you no
longer need an in-house standard on how to do that.

Sufficiently advanced test environments typically have the ability
to serve entirely custom versions of web apps, but as more application
code lives in the browser (in JS), it becomes vital to have a good
standard for testing also in the web platform layer.

Without exposing this attribute on the navigator object, it becomes
hard to make decisions about code that executes before the document
finishes loading.  By the point WebDriver returns control to the
user after loading a document, it may be too late to invoke
executeScript("window.isTest = true").

Whatever the web author uses navigator.webdriver for, if their test
strategy to begin with is not sound, then there is little we can
do to protect them from using the attribute as a foot-gun.  They
might want to test that their site still works in production before
publishing.

In the Blink intent-to-ship thread [1] they cite anti-abuse use
cases for navigator.webdriver, where a foreign website you don’t
own could use it to block unsolicited bots/crawlers.  As I also
mention in the commit message [2], this is not what the attribute
is designed for.

For better or worse (though probably the better!) the source code
of all the major browser engines are available for anyone to
scrutinise, and given the ability to compile custom browsers it is
not really a technically sound argument to make that navigator.webdriver
can realistically be used as an anti-abuse measure.

  [1] 
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/6GysDZCWwB8/rXbGoRohBgAJ
  [2] https://reviewboard.mozilla.org/r/216250/diff/4#index_header

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

Re: Intent to Ship - Support already-enrolled U2F devices with Google Accounts for Web Authentication

[J.C. Jones]

Henri,

I think there's value in providing an impetus to Google Accounts to migrate
from U2F-style enrolled credentials to Web Authentication-style. That said,
I agree, it shouldn't be an ongoing maintenance burden.

Thanks, all, for the input on this intent-to-ship. I've filed Bug 1436078
 for this work.

On Fri, Feb 2, 2018 at 1:20 AM, Henri Sivonen  wrote:

> On Tue, Jan 30, 2018 at 6:49 PM, J.C. Jones  wrote:
> > I also recognize that Google
> > Accounts is the largest player in existing U2F device enrollments.
> ...
> > If we choose not to do this, Google Accounts users who currently have U2F
> > enabled will not be able to authenticate using Firefox until their
> existing
> > U2F tokens are re-enrolled using Web Authentication -- meaning not only
> > will Google need to change to the Web Authentication API, they will also
> > have to prompt users to go back through the enrollment ceremony. This
> > process is likely to take several years.
>
> This seems like a necessary practical reason to make a special
> accommodation for user's of Google Accounts.
>
> > After discussions with appropriate Googlers confirmed that the “
> > www.gstatic.com” origin used in U2F is being retired as part of their
> > change-over to Web Authentication, I propose to hard-code support in
> Gecko
> > to permit Google Accounts’ cross-origin U2F behavior, the same way as
> > Chrome has. I propose to do this for a period of 5 years, until 2023, and
>
> Given that users may use their current token for many years, why do we
> have to set any particular expiration date for this exception? After
> implementing the exception in the first place has become a sunk cost,
> is there a reason to believe it will have a large ongoing maintenance
> burden?
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to use Gecko in my web browser as web engine

[Henri Sivonen]

Jolla ships Sailfish Browser that uses Gecko with a Qt UI. The
bindings are at
https://git.merproject.org/mer-core/qtmozembed/tree/master

On Thu, Feb 1, 2018 at 12:00 PM, Emilio Cobos Álvarez  wrote:
> I think probably dev-platform is a better list to get an answer
> regarding Gecko embedding, rather than dev-tech-layout, so posting there.
>
> I wish I could be more helpful, but I know nothing about that :).
>
>  -- Emilio
>
> On 1/31/18 8:23 AM, malay emailme wrote:
>> Dear Sir,
>>I want to build a web browser in qt and i want gecko as my
>> default web engine.Please guide me how to use.
>>  from
>> malay
>> ___
>> dev-tech-layout mailing list
>> dev-tech-lay...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-layout
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform



-- 
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: Gecko-visible Latin1 analog of JS_NewUCString()

[Henri Sivonen]

On Tue, Feb 6, 2018 at 5:44 PM, Jan de Mooij  wrote:
> I don't think so. We could add JS_New(Latin1)String that takes Latin1Char*
> instead of char16_t* (like JS_NewUCString, it can just forward to
> js::NewString).

Thanks. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1436065

-- 
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: Gecko-visible Latin1 analog of JS_NewUCString()

[Jan de Mooij]

I don't think so. We could add JS_New(Latin1)String that takes Latin1Char*
instead of char16_t* (like JS_NewUCString, it can just forward to
js::NewString).

Hope this helps,
Jan

On Tue, Feb 6, 2018 at 3:36 PM, Henri Sivonen  wrote:

> Does SpiderMonkey expose a Latin1 analog of JS_NewUCString() for Gecko to
> call?
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship navigator.webdriver

[Andreas Tolfsen]

Also sprach Boris Zbarsky:

> And in particular, the implementation patches don't match the intent
> description (e.g. we implement a configurable property)

Making it unforgeable is obviously a rather bad idea.  I did mean
that the attribute is _configurable_.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship navigator.webdriver

[Andreas Tolfsen]

Also sprach Boris Zbarsky:

> On 2/5/18 11:37 AM, Andreas Tolfsen wrote:
>> Standard:
>> https://w3c.github.io/webdriver/webdriver-spec.html#interface
> 
> All the IDL snippets in this standard are empty, which makes it
> hard to evaluate the standard or how our implementation aligns with
> it.

Through a series of unfortunate events, it appears a new version
of ReSpec was released in close proximity to my intent-to-ship
email.  That broke parsing of the WebIDL interface, but I didn’t
notice because I had it cached in my local browsing session.

In any case the interface is now back in the spec, but I will quote
it here for posterity:

> Navigator includes NavigatorAutomationInformation;
> 
> interface mixin NavigatorAutomationInformation {
>   readonly attribute boolean webdriver;
> };

Sorry about that.

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

Gecko-visible Latin1 analog of JS_NewUCString()

[Henri Sivonen]

Does SpiderMonkey expose a Latin1 analog of JS_NewUCString() for Gecko to call?

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