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
Gecko68 #993
Conversation
…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
Differential Revision: https://phabricator.services.mozilla.com/D29012 --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
Differential Revision: https://phabricator.services.mozilla.com/D29077 --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
…s at test_swapFrameLoaders.xul.
…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
…ane. r=aswan Differential Revision: https://phabricator.services.mozilla.com/D29955 --HG-- extra : moz-landing-system : lando
… on test_certs.js. CLOSED TREE
…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
…at object-inspector/types
…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
Differential Revision: https://phabricator.services.mozilla.com/D29814 --HG-- extra : moz-landing-system : lando
Differential Revision: https://phabricator.services.mozilla.com/D29815 --HG-- extra : moz-landing-system : lando
Differential Revision: https://phabricator.services.mozilla.com/D29816 --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)
This reverts commit d812ac4.
…nces; r=bsmedberg" This reverts commit d33a528.
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 -
Thanks for your interest, I hope this explanation helps clarify. :) |
No description provided.