Re: Intent to unship: hasFeature() method on some SVG elements

[墨俊凱 / Cameron McCormack]

On Fri, May 3, 2019, at 8:31 PM, Christopher Mills wrote:
> On Fri, May 3, 2019 at 3:38 AM Cameron McCormack  wrote:
>> The hasFeature() method on some SVG elements comes from SVG 1.0 and was 
>> intended to be used as part of SVG's extension mechanisms. This function 
>> never returned anything other than false in browser implementations, and was 
>> removed in SVG 2. Chrome no longer supports this, although WebKit still 
>> does. I don't anticipate any issue removing this.
>> 
>>  The removal is being done in 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1133175.
> 
> The referenced bug references SVGTests.hasExtension; what's the correct one? 

The method is defined on SVGTests, which is a mixin interface implemented by 
some specific SVG element interfaces (like SVGGraphicsElement).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to how we track regressions in Bugzilla

[Emma Humphries]

Thanks for everyone's feedback.

We're starting on the implementation in these bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=1542378 (enter bug form),
https://bugzilla.mozilla.org/show_bug.cgi?id=1545258 (create new field),
and https://bugzilla.mozilla.org/show_bug.cgi?id=1543876 (migrate existing
metadata).

I will follow up when we are ready to enable the field in production
Bugzilla.

-- Emma

On Mon, Apr 29, 2019 at 3:15 PM Emma Humphries  wrote:

> We are making more changes to how we report and track regressions in
> Bugzilla.
>
>
> There are multiple fields and keywords we use to track regressions in
> Bugzilla. It’s confusing and the fields are used inconsistently across
> teams.
>
>
> We are consolidating these fields to reduce confusion and provide a
> consistent way to track these bugs. This change will also improve our
> understanding of defects by humans,  tools and automation.
>
>
> == The Change
>
>
> You have already seen the first part of this work. We’ve added the
> regresses and regressed_by fields to identify the bug associated with the
> changeset that caused a regression. That step eliminated the confusion over
> if a bug caused a regression or was a dependency.
>
> Currently we use the regression and regressionwindow-wanted keywords to
> indicate regressions and look for the changeset responsible. We also have
> the has-regression-range field (which is used less frequently.)
>
> We’re replacing the regression and regressionwindow-wanted keywords, and
> the has-regression-range field with is_regression, which has the values:
>
>
>-
>
>yes-range-known
>-
>
>yes-range-needed
>-
>
>yes-range-not-needed
>-
>
>unsure
>-
>
>no
>-
>
>'---'
>
> We have yes-range-not-needed as a value because there are some
> long-standing regressions we know of, and also to preserve history on
> older, resolved regression bugs for which we may not know the cause or for
> which finding the range would be too expensive or difficult to find.
> == Usage
>
>
> The default value of is_regression is '---'.
>
> If you believe a bug is a regression, but don’t know what commit
> introduced it, set is_regression to yes-range-needed.
>
> If you are not sure if a bug is a regression, set is_regression to unsure.
>
>
> Once you’ve found the changeset that introduced the regression, set
> is_regression to yes-range-known and set the regressed_by field to the
> bug containing the changeset.
>
> If a bug turns out to not be a regression, set is_regression to no and
> make sure regressed_by is empty.
>
> If you set is_regression to yes-range-not-needed, then you’re asserting
> that there’s not a changeset you can revert to fix the regression.
>
> If you are looking for regressions to find ranges for, search on
> is_regression = yes-range-needed.
>
> Bugs with is_regression = unsure need help confirming if they are
> regressions. If you can confirm it’s a regression set the value to
> yes-range-needed, or yes-range-known. If not, set the value to no.
>
> We will notify triage owners through setting a needinfo request via the
> Autonag Bot when these fields are in an inconsistent state (see below).
>
>
> == Notes
>
>
> The is_regression field is intended for bugs of type defect.
>
> We will be updating our UI for bug entry so that when setting a bug
>
> So that we don’t lose history in the move, we will have to note older,
> resolved regression bugs for which we don’t have values for the
> regresses/regressed_by fields. If the bug is a regression which was RESOLVED
> FIXED or RESOLVED VERIFIED, we will mark it as yes-range-known, and look
> into backfilling the field using the information in the blocked_by field.
>
> These changes were discussed, at length, on Bugzilla (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1534280)
>
>
> == Feedback
>
>
> I'll be reading your feedback on this on this thread, or in the bugzilla
> bug and will respond later this week.
>
>
> -- Emma
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

[Gijs Kruitbosch]

On 01/05/2019 19:01, Bobby Holley wrote:

This thread is getting long, so here's a quick recap:
* It it well-understood that a number of developers use --disable-e10s as a
debugging aid, so more +1s to that effect aren't needed.
* The "please speak up" is aimed at developers who want to _remove_ 1proc
support.
* The compromise plan of record is to keep a small subset of 1proc tests as
tier-1. So basic functionality should continue to work, but stuff around
the edges may break.
* Alternative proposals to the above are welcome, but please be concrete
and weigh the trade-offs.
* If there's specific functionality you want to keep testing in 1proc mode,
please mention it in bug 1548035.

To add a bit more motivation for the proposed plan: Continuing to run the
entire test suite in 1proc mode costs money and developer time. The quality
bar of builds that ship to users is _much_ higher than the bar for builds
used as debugging hacks. If a single test starts failing in 1proc mode
only, the right answer is probably to turn the test off rather than spend
developer time chasing it. What we want to prevent are the sort of
across-the-board breakages that make the browser unusable for debugging -
and we can detect those with a much smaller subset of tests than what we're
presently running.


I think narrowing test coverage for 1proc on 69 is fine, but I'd like to 
do something for 68 still. Specifically, I strongly feel we should not 
continue to support the "turn off e10s with a pref" scenario when it's 
so loosely tested - as you said, the bar for builds that ship to users 
is much higher. On nightly, about:newtab/home (activity stream) is 
completely broken and the bug to fix it was marked wontfix due to us not 
supporting e10s (this bustage relates to the privileged content process 
which is held to nightly, so won't ride the trains with 68... but no 
idea what other bustage there might be that will [ride the trains]).


So, although this is in addition to what you're suggesting, a concrete 
proposal: I've put up a patch at 
https://phabricator.services.mozilla.com/D29892 / 
https://bugzilla.mozilla.org/show_bug.cgi?id=1548941 .


This continues supporting the pref for:

- non-Firefox (hi TB/Fennec/SM/...)
- automation
- non-official builds (like local developer builds)

In official builds, the pref will be ignored and e10s is always turned 
on. The only way to turn it off there is the environment variable 
MOZ_FORCE_DISABLE_E10S which we already supported (so if you desperately 
needed to debug something in non-e10s on an official build, you still 
could).


For 69, I think we could remove the pref entirely and transition 
everything into the env var (incl. test suites, where 1proc ones 
currently just flip the pref), to further reduce confusion and 
maintenance burdens, and I'd plan to remove various bits of browser 
chrome code specific to (non-critical) bits of non-e10s.


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

Re: Intent to unship: typeMustMatch attribute on elements

[Mike Taylor]

On 5/3/19 4:06 AM, Frederik Braun wrote:

In bug 1548773, annevk suggested to unship the `typeMustMatch`attribute
from  elements[1].

No other browser supports this and we have just learned that this
attribute can be used to leak information about cross-origin resources[2].

While it seems worth removing immediately to me, I'm interested in
additional feedback.


I ran a search on BigQuery over HTTP Archive data (just for desktop) and 
here are the results:




I only looked at 10 random items, and nothing seemed alarming -- just 
enumeration of attributes, or mapping strings to props, or regular 
expressions looking for valid attributes.


(Might be worth someone putting in more than 5 minutes of poking around 
though).


--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Avoid |mach try| task generation by running it in the background

[Kartikaya Gupta]

This is great, thank you!

On Fri, May 3, 2019 at 10:08 AM Andrew Halberstadt  wrote:
>
> If you use |mach try fuzzy| or |mach try chooser|, you've probably noticed
> the line:
> Task configuration changed, generating target task set
>
> Followed by a 20-30 second delay as we rebuild the taskgraph locally. I
> just landed a change in bug 1546757 to make it easier to use watchman
> to do this computation in the background whenever a file under /taskcluster
> is modified. With this feature enabled re-generating in the foreground will be
> extremely rare.
>
> Follow the instructions here to get it set up:
> https://firefox-source-docs.mozilla.org/tools/try/tasks.html#configuring-watchman
>
> While watchman purportedly works everywhere, I haven't personally tested
> the trigger across platforms. So if you run into issues please ping me or
> file a bug under Firefox Build System :: Try.
>
> Cheers,
> Andrew
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Avoid |mach try| task generation by running it in the background

[Andrew Halberstadt]

If you use |mach try fuzzy| or |mach try chooser|, you've probably noticed
the line:
*Task configuration changed, generating target task set*

Followed by a 20-30 second delay as we rebuild the taskgraph locally. I
just landed a change in bug 1546757
 to make it easier to
use watchman 
to do this computation in the background whenever a file under /taskcluster
is modified. With this feature enabled re-generating in the foreground will
be
extremely rare.

Follow the instructions here to get it set up:
https://firefox-source-docs.mozilla.org/tools/try/tasks.html#configuring-watchman

While watchman purportedly works everywhere, I haven't personally tested
the trigger across platforms. So if you run into issues please ping me or
file a bug under Firefox Build System :: Try.

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

Re: Intent to unship: typeMustMatch attribute on elements

[Anne van Kesteren]

On Fri, May 3, 2019 at 11:06 AM Frederik Braun  wrote:
> In bug 1548773, annevk suggested to unship the `typeMustMatch`attribute
> from  elements[1].

I've now also changed the HTML standard in
https://github.com/whatwg/html/pull/4590 and updated WPT in
https://github.com/web-platform-tests/wpt/pull/16656.


> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1548773
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: hasFeature() method on some SVG elements

[Christopher Mills]

On Fri, May 3, 2019 at 3:38 AM Cameron McCormack  wrote:

> The hasFeature() method on some SVG elements comes from SVG 1.0 and was
> intended to be used as part of SVG's extension mechanisms.  This function
> never returned anything other than false in browser implementations, and
> was removed in SVG 2.  Chrome no longer supports this, although WebKit
> still does.  I don't anticipate any issue removing this.
>
> The removal is being done in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1133175.
>

The referenced bug references SVGTests.hasExtension; what's the correct
one?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: typeMustMatch attribute on elements

[Frederik Braun]

Hi,

In bug 1548773, annevk suggested to unship the `typeMustMatch`attribute
from  elements[1].

No other browser supports this and we have just learned that this
attribute can be used to leak information about cross-origin resources[2].

While it seems worth removing immediately to me, I'm interested in
additional feedback.

Thanks,
Freddy

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1548773
[2]
https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels#object-typemustmatch
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Soft code freeze for Firefox 68 starts May 6

[Julien Cristau]

Hi all,

On May 6, we will be merging Firefox 68 from mozilla-central to beta
for the first time. In order to avoid invalidating the testing we get
out of late Nightly and the early Developer Edition builds and to ensure
that we can roll out Beta 68 to a wider audience with confidence, we'd
like to ask that any risky changes be avoided from May 6 until after
the version bump to 69 on May 13. Please also be mindful of any
landings between now and Monday as there will be very little
buffer between the first merge and shipping the 68.0b1 builds.

Some reminders for the soft code freeze period:

Do:
- Be ready to backout patches that cause crash spikes, new crashes,
severe regressions
- Monitor new regressions and escalate merge blockers
- Support release management by prioritizing fixing of merge blockers

Do Not:
- Land a risky patch or a large patch
- Land new features (that affects the current Nightly version) — be
mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can
lead to unexpected CI results
- Flip prefs that enable new Features that were untested in Nightly cycle
- Plan to kick off new experiments that might impact a feature's merge
readiness

Please let us know if you have any questions/concerns.

Thanks,
Julien, for the Release Management Team
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform