Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gecko68 #993

Closed
wants to merge 10,000 commits into from
Closed

Gecko68 #993

wants to merge 10,000 commits into from

Conversation

Ibuprophen
Copy link

@Ibuprophen Ibuprophen commented May 25, 2019

No description provided.

badboy and others added 30 commits April 26, 2019 19:19
…tions r=chutten

Differential Revision: https://phabricator.services.mozilla.com/D28847

--HG--
extra : moz-landing-system : lando
As the purpose of adjusting time is to make the start of the playback to align to zero, so the result should not be negative.

However, we can't always ensure the demuxed start time is correct, the decoded first frame sample time might be different with the time demuxer provides.

Even if we try to update the start time when we get the first decoded sample, there is still a problem because a decoder might return samples with different order, which means the first frame the decoder returns is probably not a real first frame.

Therefore, using warning to help us knows how many this situaion would be.

Differential Revision: https://phabricator.services.mozilla.com/D28432

--HG--
extra : moz-landing-system : lando
… r=sfink,jmaher

Differential Revision: https://phabricator.services.mozilla.com/D28830

--HG--
extra : moz-landing-system : lando
… in workers, r=Ehsan

Differential Revision: https://phabricator.services.mozilla.com/D28949

--HG--
extra : moz-landing-system : lando
…rhunt,kats

We need to do this separately in the WR and non-WR codepaths for picking up
scroll updates for skipped paints.

Differential Revision: https://phabricator.services.mozilla.com/D29061

--HG--
extra : moz-landing-system : lando
Differential Revision: https://phabricator.services.mozilla.com/D29065

--HG--
extra : moz-landing-system : lando
…nd::GetCommandStateParams() and call internal GetCommandStateParams() method which take TextEditor directly r=m_kato

This patch makes `EditorCommand` implement
`nsIControllerCommand::GetCommandStateParams()` and then, makes it call internal
`GetCommandStateParams()` method which takes `TextEditor` or `nsIEditingSession`
instead.

This makes each implementation really simpler.

Differential Revision: https://phabricator.services.mozilla.com/D28696

--HG--
extra : moz-landing-system : lando
…s take nsCommandParams& instead of nsICommandParams* r=m_kato

Now, all callers of `GetCurrentState()` have reference or pointer to
`nsCommandParam`.  So, taking the concrete class makes sense.

Differential Revision: https://phabricator.services.mozilla.com/D28697

--HG--
extra : moz-landing-system : lando
…as possible r=m_kato

Differential Revision: https://phabricator.services.mozilla.com/D28698

--HG--
extra : moz-landing-system : lando
We use nsSVGUtils::GetTransformMatrixInUserSpace to support
CSS transform in getCTM.

Differential Revision: https://phabricator.services.mozilla.com/D28969

--HG--
extra : moz-landing-system : lando
…nsformMatrixInUserSpace r=longsonr

Since now most CSS transform related bugs are fixed, it's clear that the
purpose of nsSVGUtils::GetTransformMatrixInUserSpace() should solely be to
replace SVGElement::PrependLocalTransformsTo(eUserSpaceToParent).

After fixing Bug 972041, the only other usecase (Bug 1247218) no longer exists.

OTOH, there is a problem when the parent has a viewbox transform, in that case,
SVGElement::PrependLocalTransformsTo() doesn't include it, but
nsLayoutUtils::GetTransformToAncestor() does.

In fact, it's much easier to compute the transform matrix directly based on
the implementation of nsDisplayTransform::GetResultingTransformMatrixInternal(),
which is also the function internally called by nsLayoutUtils::GetTransformToAncestor().

In particular, we don't need to look at 3D stuff since our matrix is inherently 2D.

Differential Revision: https://phabricator.services.mozilla.com/D28970

--HG--
extra : moz-landing-system : lando
…ocgroup boundaries. r=mats

Just make the iframe to test cloning same-origin using srcdoc, instead of using
SpecialPowers to access cross-origin objects.

Differential Revision: https://phabricator.services.mozilla.com/D28301
…ument layout across docgroup boundaries. r=surkov

We're going to stop propagating these flushes up since they're not observable by
content and it matches what would happen in a fission world.

This test relies on the parent document layout tree being up-to-date by the time
we run the iframe load handler. Also improve diagnostics in the case the
assertion fails.

Differential Revision: https://phabricator.services.mozilla.com/D28300
…ntent.xul. r=masayuki

The iframe test runs on an cross-docgroup iframe, even though chrome JS can
observe it in this test.

This test is relying on the getBoundingClientRect() call below in order to flush
the parent document layout as well, but that's going to stop happening (see the
bug and patch).

Differential Revision: https://phabricator.services.mozilla.com/D28302
…ushing. r=bzbarsky

This flush used to happen from snapshotWindow's innerWidth / innerHeight /
scroll* getters.

Differential Revision: https://phabricator.services.mozilla.com/D28303
…. r=bzbarsky

This subtest (of test_iframe_sandbox_navigation.html) starts intermittently
failing with my first patch of this bug. It relied on the pres-context being
created when sendMouseEvent is called in order to navigate away (we only
navigate away by clicking a link if there's a link handler).

sendMouseEvent calls getBoundingClientRect() which used to do this. It no longer
does though.

I could make sendMouseEvent do that automatically using SpecialPowers or such,
or from the DOMWindowUtils code, but I think I'd prefer not to do that. This is
the only test that wasn't trivially fixable, and this awkwardness can be removed
when bug 1218456 is fixed.

Differential Revision: https://phabricator.services.mozilla.com/D28910
… working across cross-origin iframes. r=kmag

Same as the previous commit, I could make sendMouseEvent do something fancy /
special, but I'd rather not, since it's trivially fixable in the test.

Differential Revision: https://phabricator.services.mozilla.com/D28911
…ols test. r=pbro

See the rest of the patches in this bug for more context :)

Differential Revision: https://phabricator.services.mozilla.com/D28912
…zbarsky

We don't need to flush layout in the parent document if the parent and child
documents can't observe each other.

This will also match our behavior in a Fission world.

I'm not attached to the name of the function, better ideas welcome.

Differential Revision: https://phabricator.services.mozilla.com/D28217
…ible data necessary for the a11y panel to work. Allow for fetching full accessible object data via new hydrate method. r=nchevobbe

Differential Revision: https://phabricator.services.mozilla.com/D28752

--HG--
extra : moz-landing-system : lando
…lculate once. Rename ColorContrastScores constant to SCORES to be used by all checks. r=nchevobbe

Differential Revision: https://phabricator.services.mozilla.com/D28753

--HG--
extra : moz-landing-system : lando
…olated clipboard job. r=masayuki

fixed editor/libeditor mochitests to work outside of isolated clipboard job.

Differential Revision: https://phabricator.services.mozilla.com/D28837

--HG--
extra : moz-landing-system : lando
ccoroiu and others added 28 commits May 6, 2019 00:42
…ane. r=aswan

Differential Revision: https://phabricator.services.mozilla.com/D29955

--HG--
extra : moz-landing-system : lando
…s. r=jmaher

Differential Revision: https://phabricator.services.mozilla.com/D29967

--HG--
extra : moz-landing-system : lando
…ts.h. r=dholbert

Converting the NS_STYLE_BORDER definitions in to enumerated classes as
per bug 1277133.

The original constants broke the convention used by the rest of the
definitions as the CSS property being described is `border-collapse`,
so corrections were made with the migration to the enumerated class.

Differential Revision: https://phabricator.services.mozilla.com/D29951

--HG--
extra : moz-landing-system : lando
…johannh,aswan

Differential Revision: https://phabricator.services.mozilla.com/D27734

--HG--
extra : moz-landing-system : lando
…ew users. r=johannh

Wait 30 min after a new profile is created before showing the onbording.

Differential Revision: https://phabricator.services.mozilla.com/D29762

--HG--
extra : moz-landing-system : lando
Typically this would be handled by the visible region of the layer
changing. However, since we build the container layer for the filter
item directly the visible region doesn't get set or checked. As a
shortcut to using more of FLB we just ensure the building rect hasn't
changed.

The situations under which this bugs shows up are somewhat rare:
- The filtered item needs to be in transform so that it's bounds
  are not changed by scrolling.
- The filtered item needs to contain items that change their drawing
  depending on the building rect. In this case an image with downscale
  on decode.
- The filter needs to be unsupported by WebRender.

Differential Revision: https://phabricator.services.mozilla.com/D29879

--HG--
extra : moz-landing-system : lando
…profilingScripts no longer implies IsLCovEnabled. r=nbp

Differential Revision: https://phabricator.services.mozilla.com/D28952

--HG--
extra : moz-landing-system : lando
…raded on startup. r=mikedeboer a=Aryx

Differential Revision: https://phabricator.services.mozilla.com//D30004

--HG--
extra : rebase_source : 6637570bb828dfc86b1d0abfbafbd1cfdd12c9d8
extra : amend_source : 4803b6d8220d7d07a8a4f9562d4297090099a183
…547688, bug 1547452, bug 1540777, bug 1542669, bug 1547454) for causing bug 1549362.

Backed out changeset 8dca7df29492 (bug 1548788)
Backed out changeset 688f361e8bb6 (bug 1547688)
Backed out changeset b5d8d57838a3 (bug 1540777)
Backed out changeset d1bd31177b14 (bug 1513937)
Backed out changeset df97dfbb526a (bug 1546310)
Backed out changeset ade08d6dc361 (bug 1547454)
Backed out changeset b622431054b7 (bug 1547452)
Backed out changeset ad73e5604411 (bug 1542669)
@laniakea64
Copy link

Apparently I wasn't clear about what needed to be done to submit your changes correctly. Sorry about that.

Again, your fork looks good, but unfortunately the pull request submission still didn't work. Now it's trying to merge the gecko68 branch into master, without even involving your fork.

In order to submit your changes correctly, you should only need to do this -

  1. Click this link - gecko68...ibuprophen1:gecko68

  2. Click the green "Create pull request" button - you should now see this

Screen Shot 2019-05-25 1

  1. You can edit the "Update all.js" title or the description under "Write" if you like, but do not make other changes. In particular, do not touch the "base repository", "base", "head repository", and "compare" drop-downs - leave those as shown.

  2. Click "Create pull request". If it submitted correctly, your pull request should show you want to merge 1 commit into MrAlex94:gecko68 from ibuprophen1:gecko68.

Thanks for your interest, I hope this explanation helps clarify. :)

@Ibuprophen Ibuprophen closed this May 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet