Gecko68 #993

…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

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

…es. r=nchevobbe Differential Revision: https://phabricator.services.mozilla.com/D28214 --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

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

…/ on windows10-aarch64 that cause task to abort r=jmaher Changes: - disable wholesale the `media-source` subsuite within web-platform-test Attempts were made to isolate the tests that cause the test harness to lock up with a permission issue on `Ahem.ttf` however the attempts were unsuccessful in isolating the tests to a manageable set. It appears the solution is to simply stop running `media-source` tests on windows10-aarch64 as that seems to have solved the problem in a previous try run. Differential Revision: https://phabricator.services.mozilla.com/D28778 --HG-- extra : moz-landing-system : lando

…res. r=jmaher Differential Revision: https://phabricator.services.mozilla.com/D29090 --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

…AST code isn't being built (e.g. when the next uplift to beta happens). r=bustage

…LOSED TREE

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

… explicit r=jfkthame

# ignore-this-changeset Differential Revision: https://phabricator.services.mozilla.com/D28948 --HG-- extra : moz-landing-system : lando

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

Backed out changeset 037390836504 (bug 1535697) Backed out changeset ebad998aae7a (bug 1535697) Backed out changeset 969945148b3d (bug 1535697) Backed out changeset 5cbdeb635a3e (bug 1535697) Backed out changeset c316d49df8c4 (bug 1535697) Backed out changeset 4a5475f6aa49 (bug 1535697) Backed out changeset 9191d987a9e1 (bug 1535697)

…nd correctly. r=gl Differential Revision: https://phabricator.services.mozilla.com/D29085 --HG-- extra : moz-landing-system : lando

… on iframes. r=mconley Differential Revision: https://phabricator.services.mozilla.com/D28920 --HG-- extra : moz-landing-system : lando

…ack expectation for OS X 10.10.5 removed by accident, caused permafails. CLOSED TREE --HG-- extra : rebase_source : 8a6d23de92b1a9bd527b6a42c152d2747e14038d

…rnal pages are no longer affected, r=mconley,flod This warning was added in https://bugzilla.mozilla.org/show_bug.cgi?id=1047586 . As a result of https://bugzilla.mozilla.org/show_bug.cgi?id=1528712 , internal pages are no longer affected by this change. Instead, they obey the OS font size configuration, in which we cannot warn. So let's remove the now-inaccurate warning dialog. Differential Revision: https://phabricator.services.mozilla.com/D29218 --HG-- extra : moz-landing-system : lando

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

…moval to Stop(). r=bryce These are added in start, and we get into unexpected state if they notify us after Stop() (when MediaEncoder shuts down and internally removes the tracks it is encoding) but before Shutdown() when we remove the listeners. This is not symmetrical. The proper thing to do is to remove these listeners in Stop() as well. Depends on D29080 Differential Revision: https://phabricator.services.mozilla.com/D29081 --HG-- extra : moz-landing-system : lando

Bug 1052579 introduced a new mozjemalloc arena for JSString char buffers. Unfortunately, my testing missed the case where JSStringBuilder causes an OOM condition, causing the OOM handler to realloc to the default arena, regardless of what arena is actually indicated by the AllocPolicy for the char vector. The realloc now passes the arena from the AllocPolicy to mozjemalloc. Differential Revision: https://phabricator.services.mozilla.com/D29092 --HG-- extra : moz-landing-system : lando

Turn on frameloader rebuilding on process switch for all browsers. Differential Revision: https://phabricator.services.mozilla.com/D27805 --HG-- extra : moz-landing-system : lando

…it/content/tests/chrome/test_findbar_entireword.xul Backed out changeset 31a0bd977b2f (bug 1322385) Backed out changeset feef45c56170 (bug 1322385)

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

Fix web-platform-tests on windows/aarch64 Differential Revision: https://phabricator.services.mozilla.com/D29386 --HG-- extra : moz-landing-system : lando

…ks to see why it's failing r=KevinJacobs Crashes as a result of 2e4a7bcc1a95 indicate that InitializeNSSWithFallbacks is failing. Hopefully this will give us more information as to why. Differential Revision: https://phabricator.services.mozilla.com/D29034 --HG-- extra : moz-landing-system : lando

This matches other UAs. Differential Revision: https://phabricator.services.mozilla.com/D14848 --HG-- extra : moz-landing-system : lando

…bert This won't reintroduce any of the regressions that were triggered by our previous attempts to turn off -moz prefixed gradients, and lets us massively simplify the gradient code, if it sticks. Differential Revision: https://phabricator.services.mozilla.com/D29346 --HG-- extra : moz-landing-system : lando

…OSED TREE --HG-- extra : rebase_source : aae1090ddfd8445a8cf03385dc200c65f4acd2e0

…koview for frequent intermittent failures; r=jmaher Differential Revision: https://phabricator.services.mozilla.com/D28747 --HG-- extra : moz-landing-system : lando

…th ccache; r=chmanchester Using `ccache` apparently interferes with how flag checking is done when we're using `clang` as our compiler. We can work around this by adding a few more flags to flag checking. Differential Revision: https://phabricator.services.mozilla.com/D28895 --HG-- extra : moz-landing-system : lando

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

…OSED TREE

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

…r=kats WebRender has been on in Nightly on AMD hardware for a while with no complaint. Let's let it ride further. Differential Revision: https://phabricator.services.mozilla.com/D29416 --HG-- extra : moz-landing-system : lando

…ard/gpu test locally, r=jmaher This was a regression from bug 1546100. Differential Revision: https://phabricator.services.mozilla.com/D29390 --HG-- extra : moz-landing-system : lando

…ather than thebes callbacks. r=jrmuizel This provides glyph-extents support for these fonts, so that fallback diacritic positioning can work. In principle we could try switching to the hb_ot_font functions for all fonts, but this carries some risk of disrupting other issues: (1) on some platforms, our glyph-advance callbacks use platform APIs rather than reading the font file directly, in order to respect hinting that may be in effect; and (2) the hb_ot_font functions don't currently provide fallbacks for CJK Compatibility Ideographs Standardized Variants, as implemented for Gecko in bug 989557, so that case would be regressed. Hence, for the time being switching only for OpenType/CFF fonts, where the thebes callbacks are known to be incomplete (no glyph-extents support) is the safer, more conservative approach. Differential Revision: https://phabricator.services.mozilla.com/D29010 --HG-- extra : moz-landing-system : lando

…ted<MyContainer> c(cx, MyContainer(cx))` if possible r=jonco Differential Revision: https://phabricator.services.mozilla.com/D26797 --HG-- extra : moz-landing-system : lando

…r=bzbarsky Temporary workaround to prevent wrapper assertions in torn-down window. Differential Revision: https://phabricator.services.mozilla.com/D29410 --HG-- extra : moz-landing-system : lando

… logic r=keeler Differential Revision: https://phabricator.services.mozilla.com/D29384 --HG-- extra : moz-landing-system : lando

…s r=jonco Differential Revision: https://phabricator.services.mozilla.com/D29302 --HG-- extra : moz-landing-system : lando

… 1.34. r=dmajor Differential Revision: https://phabricator.services.mozilla.com/D29307 --HG-- extra : moz-landing-system : lando

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

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

…rker and generic-worker; r=dustin Differential Revision: https://phabricator.services.mozilla.com/D24238 --HG-- extra : moz-landing-system : lando

…pond to workers with aliases; r=dustin Differential Revision: https://phabricator.services.mozilla.com/D24239 --HG-- extra : moz-landing-system : lando

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

NSS uplift, 30 April 2019. Commit log: https://hg.mozilla.org/projects/nss/log?rev=e5e10a46b9ad..56826bedabba Differential Revision: https://phabricator.services.mozilla.com/D29382 --HG-- extra : moz-landing-system : lando

…y.js; r=baku Differential Revision: https://phabricator.services.mozilla.com/D29399 --HG-- extra : moz-landing-system : lando

…ks to see why it's failing r=KevinJacobs Crashes as a result of 2e4a7bcc1a95 indicate that InitializeNSSWithFallbacks is failing. Hopefully this will give us more information as to why. Differential Revision: https://phabricator.services.mozilla.com/D29034 --HG-- extra : moz-landing-system : lando

Also fixes bug 1547136. Differential Revision: https://phabricator.services.mozilla.com/D28928 --HG-- extra : moz-landing-system : lando

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

…options.

I started changing StringSplit to attach outside of self-hosted code, to match ConstStringSplit. Upon closer examination, the StringSplit IC doesn't actually add any value, and we're better off deleting it. The generated code calls StringSplitHelper, which ends up doing almost exactly the same thing as the call to intrinsic_StringSplitString it replaces. When we first wrote the patch (bug 1366377), the advantage was that we got to skip a lookup to determine the group of the resulting object. However, a subsequent patch created a single group for every StringSplitString result, which is basically free to look up. I couldn't write a microbenchmark where the StringSplit IC made any difference, so let's just delete it and simplify our codebase. Depends on D29534 Differential Revision: https://phabricator.services.mozilla.com/D29535 --HG-- extra : moz-landing-system : lando

1. In bug 1545278, Ted is making our story about guarding on object pointer identity more robust. Since I am adding a new guardSpecificObject call in the ConstStringSplit patch, it seemed reasonable to add guardSpecificFunction now instead of later. 2. It's not directly relevant in the current patch, but in a previous version of the StringSplit patch (before I realized we could delete the whole thing) it turned out that calling isSelfHostedFunctionWithName on an arbitrary function can trigger assertions, because GetSelfHostedFunctionName assumes isExtended, but isSelfHostedBuiltin does not necessarily imply isExtended (in the case of nested anonymous functions). 3. Fixing the format string in a JitSpew message I added in a previous stack. Depends on D29535 Differential Revision: https://phabricator.services.mozilla.com/D29536 --HG-- extra : moz-landing-system : lando

…ithout "new" r=mgaudet Some native functions (for example, the Array constructor) have constructor-like behaviour even when called in a non-constructing context. We still want to create template objects for these cases. This fixes a noticeable regression in Speedometer (particularly in EmberJS-debug). Depends on D29533 Differential Revision: https://phabricator.services.mozilla.com/D29534 --HG-- extra : moz-landing-system : lando

When pushing arguments for a JIT call, we push the callee value onto the stack, and then immediately pop it off. This is a remnant of the old implementation. This patch removes that wart, with a small detour to rewrite/recomment alignJitStackBasedOnNArgs for clarity. Differential Revision: https://phabricator.services.mozilla.com/D29532 --HG-- extra : moz-landing-system : lando

…rks r=mgaudet While trying to pin down a performance regression, I realized that both the new and the old implementations of ConstStringSplit are broken. Three years ago, as part of some ES6 work, we changed String.prototype.split to call a self-hosted String_split function instead of native str_split. In turn, String_split calls intrinsic_StringSplitString in the case we care about. However, because the call to intrinsic_StringSplitString is in self-hosted code, we would only get value out of this stub if there was only one caller of String_split in the entire program. This patch changes ConstStringSplit to look for the self-hosted String_Split function, which means we can attach a stub to the user script instead of self-hosted code. It also adds support in BaselineInspector for extracting metadata about the string split from the stub, which enables the Ion version of this optimization. Depends on D29532 Differential Revision: https://phabricator.services.mozilla.com/D29533 --HG-- extra : moz-landing-system : lando

…js. r=remote-protocol-reviewers,ato This allows improving all tests exceptions without requiring any specific to be done in each tests. I'm also moving a few imports to head.js to share the most into head.js. Differential Revision: https://phabricator.services.mozilla.com/D29414 --HG-- extra : moz-landing-system : lando

Consumers that just care about this boolean state should use this instead of getting the JSObject* directly. Differential Revision: https://phabricator.services.mozilla.com/D29705 --HG-- extra : moz-landing-system : lando

…pose to active JS. r=mccr8 See callsite audit in https://bugzilla.mozilla.org/attachment.cgi?id=9061976 for details on why the remaining GetGlobalJSObject callers should switch to the "always expose" behavior. Differential Revision: https://phabricator.services.mozilla.com/D29707 --HG-- extra : moz-landing-system : lando

…d IO during startup. r=johannh Differential Revision: https://phabricator.services.mozilla.com/D28990 --HG-- extra : moz-landing-system : lando

…reviewers,ato Start the `TabObserver` from `RemoteAgent.listen` in order to prevent having the tests to manually start it. Start it from `listen` instead of `init` as we do stop the `TabObserver` from `stop` and `stop` is the reverse of `listen`, not the reverse of `init`. Differential Revision: https://phabricator.services.mozilla.com/D29412 --HG-- extra : moz-landing-system : lando

…they migrate from mozilla-central. r=chutten Differential Revision: https://phabricator.services.mozilla.com/D29726 --HG-- extra : moz-landing-system : lando

…own origin; r=chutten Differential Revision: https://phabricator.services.mozilla.com/D29670 --HG-- extra : moz-landing-system : lando

This can fix the 1 color difference intermittent failure problem, it's small enough to be ignored. Differential Revision: https://phabricator.services.mozilla.com/D29773 --HG-- extra : moz-landing-system : lando

Marking GetGlobalJSObject and GetGlobalJSObjectPreserveColor final and inline on inner/outer windows allows compilers to de-virtualize and inline them, which makes them just as fast as calling FastGetGlobalJSObject is now (in the case of GetGlobalJSObjectPreserveColor; GetGlobalJSObject has to do the gray-unmarking, which is a bit more work). In WindowDestroyedEvent::Run we want to switch to GetGlobalJSObject(), because we want to root the object and hence should unmark gray. In nsGlobalWindowInner::RunTimeoutHandler we likewise want to unmark gray. The AutoEntryScript constructor likely did that already, but it's not that expensive when it doesn't need to do any work. Differential Revision: https://phabricator.services.mozilla.com/D29711 --HG-- extra : moz-landing-system : lando

…sGlobalWindowOuter. r=mccr8,jonco We store newInnerGlobal in a Rooted, so as long as we expose on all codepaths that assign to that variable (which with this patch we do, typically via GetWrapper() calls), there's no need to expose explicitly. Differential Revision: https://phabricator.services.mozilla.com/D29718 --HG-- extra : moz-landing-system : lando

…OM code. r=mccr8,jonco The call in VRFrameData::LazyCreateMatrix is not needed because aRetval.set(aArray) ends up calling into Heap::get() which does a read barrier and exposes. The call in nsXULPrototypeScript::Compile is not needed because initializing the AutoJSAPI will guarantee that the global of the Realm it enters, which is what we're examining here, will be exposed. The call in Promise's CreateNativeHandlerFunction is not needed because the object being passed in was always just-created into a stack Rooted. The call in MIDIMessageEvent::GetData is not needed because it's always working with a just-created object. Also, mData is a Heap, so there will be a read barrier anyway before anyone gets at the value. The call in PrototypeDocumentContentSink::ExecuteScript is not needed because the AutoEntryScript will guarantee that the global of the Realm it enters is exposed. And the JSAutoRealm is not needed either, because we're in that Realm already. Differential Revision: https://phabricator.services.mozilla.com/D29720 --HG-- extra : moz-landing-system : lando

… blocklist. r=jrmuizel This reunifies the behaviour changed in bug 1294232 to ensure that the vendor ID of GfxInfo is the same between graphics hardware. Vendor ID should always represent Intel, Nvidia, ATI, etc such that callers can reason about the performance characteristics without being exposed to the driver implementation for that platform. Now we split off the more detailed driver information into the "driver vendor" which will contain more information, such as what implementation is being used (e.g. mesa/i965 for modern Intel graphics cards). This field is exposed to the blocklist and will be useful for allowing different rules for different driver implementations. We also now provide a default implementation for GfxInfoBase::FindMonitors for platforms missing support. This will just list the primary screen size used without listing secondary monitors, refresh rate, and such. Differential Revision: https://phabricator.services.mozilla.com/D29471

…serveColor where possible. r=mccr8,jonco Differential Revision: https://phabricator.services.mozilla.com/D29706 --HG-- extra : moz-landing-system : lando

…d about:support. r=jrmuizel,chutten,flod data-r=bmiroglio Expose the driver vendor information (applies to Linux only at this moment) to crash report telemetry and about:support. This will be useful when debugging issues to know specifically what driver is in use. Also expose the monitor information for Linux. Part 1 provides an implementation to get the monitor information on said platform. Differential Revision: https://phabricator.services.mozilla.com/D29472

…eraction with permission prompts in Nightly. r=Ehsan Differential Revision: https://phabricator.services.mozilla.com/D29797 --HG-- extra : moz-landing-system : lando

…buffer is missing. r=kats Differential Revision: https://phabricator.services.mozilla.com/D29829

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

…ld; r=nika Differential Revision: https://phabricator.services.mozilla.com/D29427 --HG-- extra : moz-landing-system : lando

…ebrtc/RTCPeerConnection-createDataChannel.html

…a,tanvi Differential Revision: https://phabricator.services.mozilla.com/D28801 --HG-- extra : moz-landing-system : lando

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

…ec app code. r=VladBaicu Differential Revision: https://phabricator.services.mozilla.com/D29723 --HG-- extra : moz-landing-system : lando

… of a renamed file. r=Honza DONTBUILD because this is just a comment tweak. Differential Revision: https://phabricator.services.mozilla.com/D29691 --HG-- extra : moz-landing-system : lando

…ker/workspace/build/src/obj-firefox/dist/include/mozilla/dom/WindowGlobalActor.h. CLOSED TREE Backed out changeset 366f29cc8ce7 (bug 1539147) Backed out changeset 5fa4ae41da87 (bug 1539147)

…d page-load tests on GeckoView Example App; #perftest r=davehunt Differential Revision: https://phabricator.services.mozilla.com/D29207 --HG-- extra : moz-landing-system : lando

…nd customize start so that left/right arrow and home/end keys work after exiting customize mode. r=mak When UrlbarInput.uninit is called after customize mode ends, uninit calls this.inputField.controllers.removeControllerAt(0), which is supposed to remove the input's CopyCutController inserted in the constructor. But the controller at index 0 at that point is not the CopyCutController. Instead it's some built-in controller that supports these commands (at least these): cmd_charPrevious, cmd_charPrevious, cmd_beginLine, cmd_endLine. (Verified by adding logging to nsXULControllers::GetControllerForCommand.) That's why arrow left/right and home/end don't work after ending customize mode. The problem is that this.inputField.controllers in the constructor and this.inputField.controllers in uninit (when customize mode ends) are not the same. I wasn't able to track down why, but I'm guessing that the textbox or something in its state is being reset or cloned when customized mode ends or maybe right after it starts. The CopyCutController isn't in the controllers array at all on uninit. (Verified by adding support for cmd_adw and iterating through the controllers array, looking for a controller supporting cmd_adw.) Note that urlbarBindings.xml has a try-catch around removeController(), I'm guessing for what turns out to be this reason: https://searchfox.org/mozilla-central/rev/7944190ad1668a94223b950a19f1fffe8662d6b8/browser/base/content/urlbarBindings.xml#190 However, CopyCutController *is* in the controllers array when customize mode starts. So I added a new gURLBarHandler.customizeStart method that calls a new UrlbarInput.removeCopyCutController method. Other things I tried or thought of doing: Call gURLBarHandler._reset on customize start instead of end. Problem with that is that the UrlbarInput ends up getting immediately recreated because some other parts of the browser access gURLBar at that time. (Of course I replaced the `gURLBar = this.urlbar` assignment in _reset with another lazy getter definition.) Just don't worry about removing CopyCutController at all. That seems bad because then we'd leak it, unless the controller is removed or the controllers array is emptied at some point by XUL, and I'm not at all certain about that. (Although I guess this is effectively what awesomebar does, given the link above!) Differential Revision: https://phabricator.services.mozilla.com/D29613 --HG-- extra : moz-landing-system : lando

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

…use RootedContext. r=smaug Differential Revision: https://phabricator.services.mozilla.com/D29810 --HG-- extra : moz-landing-system : lando

… TREE Backed out changeset 215c2693d281 (bug 1544105) Backed out changeset 16d5af6fd55c (bug 1544105)

…t_snapshotting.js; r=asuth

…refs UI. r=flod,johannh * Create new network.trr.resolvers pref which is a JSON array of objects with a name and url representing each resolver * Add menulist to represent the resolver choices, and a "custom" option to use the network.trr.custom_uri as the trr.uri value Differential Revision: https://phabricator.services.mozilla.com/D29393 --HG-- extra : moz-landing-system : lando

… rotated. r=gl Differential Revision: https://phabricator.services.mozilla.com/D29308 --HG-- extra : moz-landing-system : lando

…'s sweep group edges where possible r=sfink? Rather than consulting the debugger weak maps to add reverse edges corresponding to forward edges added for cross compartment wrappers, add both forward and reverse edges when iterating the cross compartment wrapper map. Remove zone counts from debugger weak maps. Differential Revision: https://phabricator.services.mozilla.com/D29496 --HG-- extra : moz-landing-system : lando

These tests need to be disabled to get a green run on the Android x86_64 test platform. The failures in toolkit/components/extensions are concerning and definitely require follow-up. Differential Revision: https://phabricator.services.mozilla.com/D29843 --HG-- extra : moz-landing-system : lando

…tributes and nsIPrincipal, r=Ehsan,flod Differential Revision: https://phabricator.services.mozilla.com/D29353 --HG-- extra : moz-landing-system : lando

…D UNKNOWN_APP_ID, r=Ehsan Differential Revision: https://phabricator.services.mozilla.com/D29354 --HG-- extra : moz-landing-system : lando

…onmanager, r=Ehsan Differential Revision: https://phabricator.services.mozilla.com/D29355 --HG-- extra : moz-landing-system : lando

…=valentin Differential Revision: https://phabricator.services.mozilla.com/D29356 --HG-- extra : moz-landing-system : lando

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

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

…ants, a=testonly Automatic update from web-platform-tests [LayoutNG] Fix nested legacy oof descendants Another fix for "Legacy OOF descendant did not get laid out" The cause here was: - if #container had a legacy descendant, and - legacy descendant had an oof descendant whose containing block was #container, that oof descendant would get added to #container's list of legacy oof, but would never get laid out. This bug was hidden, because it would not happen if layout happened twice, which we often do. Seen in the wild at https://www.humblebundle.com/ when scrolling down. Bug: 946986 Change-Id: I183f3d5dfe79b49c5c6aadad0ee2cfcb8bb6849f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1546713 Commit-Queue: Aleks Totic <atotic@chromium.org> Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Auto-Submit: Aleks Totic <atotic@chromium.org> Cr-Commit-Position: refs/heads/master@{#646077} -- wpt-commits: 94cd32e64d89b561b803355c299c9db5908e0cb1 wpt-pr: 16158

…vated, navigational requests., a=testonly Automatic update from web-platform-tests Send `Sec-Fetch-User` only for user-activated, navigational requests. As per the conversation in w3c/webappsec-fetch-metadata#23 and w3c/webappsec-fetch-metadata#19, this patch drops the `Sec-Fetch-User` header for non-navigational requests, and for navigational requests that are not user-activated. Bug: 947444 Change-Id: Ica4846bda6ccf4e8bce1323803954f4fef9c18a3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1545871 Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Commit-Queue: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/master@{#646086} -- wpt-commits: b93752a06f9498f774aed288663259cd738f1a7c wpt-pr: 16148

…dl, a=testonly Automatic update from web-platform-tests Update interfaces/performance-timeline.idl (#16161) Source: https://github.com/tidoust/reffy-reports/blob/b9c153c/whatwg/idl/performance-timeline.idl Build: https://travis-ci.org/tidoust/reffy-reports/builds/513365425 -- wpt-commits: ecb5ceb84abcab34640cdbaf3d282b7bcb4029b5 wpt-pr: 16161

@dholbert

… a=testonly Automatic update from web-platform-tests Sync Mozilla CSS tests as of https://hg.mozilla.org/mozilla-central/rev/c06dfc552c647a6ce96f35cd84c32a589dc85608 . (#16166) This contains changes from: * [bug 1503173](https://bugzilla.mozilla.org/show_bug.cgi?id=1503173) by @dholbert, reviewed by @emilio * [bug 1514843](https://bugzilla.mozilla.org/show_bug.cgi?id=1514843) by @dholbert, reviewed by @aethanyc -- wpt-commits: f24d88b7d2cd2d851533e9c1180b1c5c5d118bc3 wpt-pr: 16166

…a=testonly Automatic update from web-platform-tests Corrected 1 error in calc-numbers.html -- wpt-commits: 3419750ac87c9f227bd1aafc8433ed4a9183728f wpt-pr: 16169

…l containers., a=testonly Automatic update from web-platform-tests Honor contain:size correctly for multicol containers. Updated the existing test for this to actually test with contain:size. Bug: 863454 Change-Id: I44ac7bd4dd875845d14476dd9b286450bbc66bf0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1545302 Commit-Queue: Emil A Eklund <eae@chromium.org> Reviewed-by: Emil A Eklund <eae@chromium.org> Cr-Commit-Position: refs/heads/master@{#646173} -- wpt-commits: b440056b54c783d18a78da25f8d31ce324e980f4 wpt-pr: 16150

…ight with justify-content, a=testonly Automatic update from web-platform-tests [css-flexbox] Correctly calculate min-height with justify-content Spacing added by justification is not meaninfully part of the intrinsic block size of an item; remove it. This is especially problematic with percentage sizes, because with height: 100% and justify-content: flex-end we would position any flex items at the end and calculate a minimum size based on the 100%, even though we ought to ignore percentages. R=dgrogan@chromium.org, eae@chromium.org Bug: 945214 Change-Id: If4e271df5e550807632d30e5dd1c2b3068d45313 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1546002 Commit-Queue: Emil A Eklund <eae@chromium.org> Reviewed-by: David Grogan <dgrogan@chromium.org> Reviewed-by: Emil A Eklund <eae@chromium.org> Auto-Submit: Christian Biesinger <cbiesinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#646178} -- wpt-commits: f326d29cb1469bf9b61d816a4752d02df706d129 wpt-pr: 16156

…nitial <url> values., a=testonly Automatic update from web-platform-tests [css-properties-values-api] Absolutize initial <url> values. The computed value would incorrectly remain relative for the initial value of <url>-registered custom properties. This is because it did not undergo the token-rewriting done for non-initial properties. Since the token-rewriting function was implemented, circumstances have changed a little: there is now a general absolutization mechanism (i.e. StyleBuilderConverter::ConvertRegisteredPropertyVariableData). Therefore, this CL performs the URL absolutization on the CSSValue-level rather than the token level. This automatically also catches the initial-value case. Note that CSSVariableDatas with var()-references would previously "forget" their base URL and TextEncoding when resolved. This didn't matter in practice, because we would already have rewritten the tokens at that point. However, it matters now, since the URL is now made absolute _after_ the CSSVariableData is resolved. Hence, CSSVariableData::CreateResolved has gained the appropriate parameters. R=futhark@chromium.org Bug: 641877 Change-Id: I0fd80664adb49e60df24dcc0e91d23872f61fdb8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1528188 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/master@{#646218} -- wpt-commits: 2f2bf34086414fb3bd8e01e92aca1aa18e7ea730 wpt-pr: 16151

…3bd8e01e92aca1aa18e7ea730, a=testonly wpt-head: 2f2bf34086414fb3bd8e01e92aca1aa18e7ea730 wpt-type: landing

--HG-- extra : rebase_source : 22fb8adc0d17677cdd3ef356934dbf3dc9d0962d

We're supposed to register this category for everything other than desktop Firefox. Instead, we currently register it only for desktop Firefox. Differential Revision: https://phabricator.services.mozilla.com/D29858 --HG-- extra : rebase_source : aaafd1704d9518dd9595c9e7229fb1ae5956acf7

…ze. r=jfkthame Instead of renaming it to mMinISize, I choose mCachedMinISize because both grid and flex container frames use mCachedMinISize for similar purpose. Differential Revision: https://phabricator.services.mozilla.com/D29747 --HG-- extra : moz-landing-system : lando

…Size. r=jfkthame Like Part 2, I choose mCachedPrefISize because grid and flex container are using it. Differential Revision: https://phabricator.services.mozilla.com/D29748 --HG-- extra : moz-landing-system : lando

…e::GetPrefISize(). r=jfkthame Differential Revision: https://phabricator.services.mozilla.com/D29749 --HG-- extra : moz-landing-system : lando

Backed out changeset dd882b8cd73e (bug 1540573) Backed out changeset b10d2cae45f2 (bug 1540573) Backed out changeset 270a8917377f (bug 1540573) Backed out changeset 3db059b34e40 (bug 1540573) Backed out changeset fe196b2dfc62 (bug 1540573) Backed out changeset 1bde5042e507 (bug 1540573) Backed out changeset 4ff116b9d729 (bug 1540573)

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

…ddon in telemetry-tests-client r=raphael Differential Revision: https://phabricator.services.mozilla.com/D29388 --HG-- extra : moz-landing-system : lando

…raphael This sometimes introduces an environment change ping when it shouldn't, and hides that install_addon doesn't actually trigger an environment change. Depends on D29388 Differential Revision: https://phabricator.services.mozilla.com/D29389 --HG-- extra : moz-landing-system : lando

…C_ISIZE_UNKNOWN. r=jfkthame This patch is generated by running the following script under layout/, and then manually delete the FIXME comment in LayoutConstants.h #!/bin/bash function rename() { find .\ -type f\ ! -path "./obj*"\ ! -path "./.git"\ ! -path "./.hg"\ $ -name "*.cpp" -or\ -name "*.h" $\ -exec sed -i -e "s/$1/$2/g" "{}" \; } rename NS_INTRINSIC_WIDTH_UNKNOWN NS_INTRINSIC_ISIZE_UNKNOWN Differential Revision: https://phabricator.services.mozilla.com/D29746 --HG-- extra : moz-landing-system : lando

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

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

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

…ld; r=nika Differential Revision: https://phabricator.services.mozilla.com/D29427 --HG-- extra : moz-landing-system : lando

…3bd8e01e92aca1aa18e7ea730: Fix typo. a=typo

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

…atchman trigger. r=ahal Otherwise `statedir` is always "" Differential Revision: https://phabricator.services.mozilla.com/D29826 --HG-- extra : moz-landing-system : lando

…s. r=bytesized This was erroneously removed in bug 1546597. Also restores the original order of writing to the update.status file in relation to reloading the update manager. Differential Revision: https://phabricator.services.mozilla.com/D29795 --HG-- extra : moz-landing-system : lando

… blocklist. r=jrmuizel This reunifies the behaviour changed in bug 1294232 to ensure that the vendor ID of GfxInfo is the same between graphics hardware. Vendor ID should always represent Intel, Nvidia, ATI, etc such that callers can reason about the performance characteristics without being exposed to the driver implementation for that platform. Now we split off the more detailed driver information into the "driver vendor" which will contain more information, such as what implementation is being used (e.g. mesa/i965 for modern Intel graphics cards). This field is exposed to the blocklist and will be useful for allowing different rules for different driver implementations. We also now provide a default implementation for GfxInfoBase::FindMonitors for platforms missing support. This will just list the primary screen size used without listing secondary monitors, refresh rate, and such. Differential Revision: https://phabricator.services.mozilla.com/D29471

We could do some work to make sure that we don't unnecessarily PushLayer, but that's better left for the future. Differential Revision: https://phabricator.services.mozilla.com/D29744 --HG-- extra : moz-landing-system : lando

…d about:support. r=jrmuizel,chutten,flod data-r=bmiroglio Expose the driver vendor information (applies to Linux only at this moment) to crash report telemetry and about:support. This will be useful when debugging issues to know specifically what driver is in use. Also expose the monitor information for Linux. Part 1 provides an implementation to get the monitor information on said platform. Differential Revision: https://phabricator.services.mozilla.com/D29472

…n UTF-8 encoding. r=jib Depends on D28252 Differential Revision: https://phabricator.services.mozilla.com/D28556 --HG-- extra : moz-landing-system : lando

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

…nder Make sure we continue to leave JS un-minified for Nightly builds and add a missing FENNEC_NIGHTLY to AppConstants.jsm which got missed in bug 1547710. Differential Revision: https://phabricator.services.mozilla.com/D29724 --HG-- extra : moz-landing-system : lando

This partially backouts the changes from 1002276e26e2. Differential Revision: https://phabricator.services.mozilla.com/D29878 --HG-- extra : moz-landing-system : lando

… remove it on backspace. r=adw Differential Revision: https://phabricator.services.mozilla.com/D29664 --HG-- extra : moz-landing-system : lando

…ing browser_Troubleshoot.js CLOSED TREE Backed out changeset eca7ee42af96 (bug 1544105) Backed out changeset a8cd879f02ce (bug 1544105)

…pass. r=kvark,nical Differential Revision: https://phabricator.services.mozilla.com/D29777 --HG-- extra : moz-landing-system : lando

…ixels r=kvark If a document has an empty rect for whatever reason (in the case observed, this was due to running a full screen video in the content document, which occludes the chrome document), then we still want to ensure that we build a frame if the texture cache has performed a clear, as otherwise we may try to access stale items from the texture resolver in render_impl. Differential Revision: https://phabricator.services.mozilla.com/D29848 --HG-- extra : moz-landing-system : lando

…cobs,mythmon,glasserc Differential Revision: https://phabricator.services.mozilla.com/D29763 --HG-- extra : moz-landing-system : lando

…hat pointers in the metadata will correctly point into the deduplicated data, not into user-provided data that hasn't been deduplicated yet. r=tcampbell Depends on D29266 Differential Revision: https://phabricator.services.mozilla.com/D29547 --HG-- extra : moz-landing-system : lando

… blocklist. r=jrmuizel This reunifies the behaviour changed in bug 1294232 to ensure that the vendor ID of GfxInfo is the same between graphics hardware. Vendor ID should always represent Intel, Nvidia, ATI, etc such that callers can reason about the performance characteristics without being exposed to the driver implementation for that platform. Now we split off the more detailed driver information into the "driver vendor" which will contain more information, such as what implementation is being used (e.g. mesa/i965 for modern Intel graphics cards). This field is exposed to the blocklist and will be useful for allowing different rules for different driver implementations. We also now provide a default implementation for GfxInfoBase::FindMonitors for platforms missing support. This will just list the primary screen size used without listing secondary monitors, refresh rate, and such. Differential Revision: https://phabricator.services.mozilla.com/D29471

…d about:support. r=jrmuizel,chutten,flod data-r=bmiroglio Expose the driver vendor information (applies to Linux only at this moment) to crash report telemetry and about:support. This will be useful when debugging issues to know specifically what driver is in use. Also expose the monitor information for Linux. Part 1 provides an implementation to get the monitor information on said platform. Differential Revision: https://phabricator.services.mozilla.com/D29472

…d invokes browsertime. r=Standard8,ahal [browsertime](https://github.com/sitespeedio/browsertime) is a harness for running performance tests, similar to Mozilla's Raptor testing framework. The Performance Team is using it locally with some success, but we're running a heavily modified toolchain that is challenging to install. This mach command is intended to be leverage for getting more folks able to use browsertime easily. In particular, the version of browsertime that this installs has nalexander's changes to support testing GeckoView-based vehicles. If this approach meets with approval, I'll continue to follow-up with additional configuration and tooling layers to make it even easier to drive GeckoView-based vehicles. I elected to piggy-back install on the eslint installation process, since this is very similar. To that end, I generalized what was there very slightly. I elected not to try to move the existing code into a more obvious shared location, although it might be possible, because it wasn't clear what contexts the existing code would be invoked from. In particular I wasn't certain the code could rely on a complete mozbuild checkout. I did need to ensure the local Node.js binary is early on the PATH; this was an issue I ran into with my initial Node/Yarn prototyping many months ago. At heart the issue is that package scripts in the wild invoke a bare `node` or `npm` command; if there was a culture of invoking $NODE or $NPM, this wouldn't be necessary. There's no harm doing it for ESlint, and it will help the next person who wants to install an NPM package for tooling in this manner. Differential Revision: https://phabricator.services.mozilla.com/D26820 --HG-- extra : moz-landing-system : lando

Under the hood, browsertime invokes a certain `visualmetrics.py` script. That script depends on `ffmpeg` and ImageMagick's `convert`, `compare`, and `mogrify` commands. It also depends on certain Python packages. So this installs those dependencies, and then wires up the evaluation environment such that `./mach browsertime` can find the dependencies. It also adds a `./mach visualmetrics` command for processing a captured MP4 file in the same way that browsertime processes such a file. In order to avoid downloading dependencies multiple time, the existing artifact cache is extracted. This is a small first step towards [Bug 1526021](https://bugzilla.mozilla.org/show_bug.cgi?id=1526021), which might want to use this artifact cache as well. At this time, hashes and filesizes are not verified. During development, the upstream files changed multiple times, and it's not worth being completely locked down while experimenting with this functionality. If we start running this code in automation or in more sensitive environments, we can build fetch tasks and TC indexes to streamline the artifact gathering process. It is expected that a future mach command will want to invoke browsertime without suffering the overhead of invoking Python (and mach, which is itself bulky) so a nod is given to exposing the relevant environment pieces. During testing, it was discovered that [MozillaBuild doesn't ship git](https://bugzilla.mozilla.org/show_bug.cgi?id=1503028), so that git repositories can't be used out-of-the-box on Windows. So instead we use a [tarball link from github.com/$USER/$REPO/tarball/$COMMIT-LIKE](https://github.blog/2008-03-03-tarball-downloads/). Differential Revision: https://phabricator.services.mozilla.com/D29442 --HG-- extra : moz-landing-system : lando

Occasionally the taskcluster fetches can fail, so make sure the requests library automatically retries if possible. Differential Revision: https://phabricator.services.mozilla.com/D29914 --HG-- extra : moz-landing-system : lando

…ilter. r=mtigley Differential Revision: https://phabricator.services.mozilla.com/D29830 --HG-- extra : moz-landing-system : lando

It turns out that an rkv database created on a 32-bit platform cannot be used on a 64-bit platform and vice-versa. To work around this for now, we delete and recreate the DB backing cert_storage and set flags to let our consumers know to re-load all known data. Differential Revision: https://phabricator.services.mozilla.com/D29591 --HG-- extra : moz-landing-system : lando

…lemetry r=jib,smaug Adding telemetry for gUM, enumerate devices, and mozRTCPeerConnection Differential Revision: https://phabricator.services.mozilla.com/D23103 --HG-- extra : moz-landing-system : lando

…ould be considered an async AGR. r=miko Differential Revision: https://phabricator.services.mozilla.com/D29796 --HG-- extra : moz-landing-system : lando

…johannh,aswan Differential Revision: https://phabricator.services.mozilla.com/D27734 --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

Backed out changeset feb726e4f15d (bug 1543247) Backed out changeset 4b3619d89abd (bug 1543247)

…20.000Z r=jcj a=lizzard Differential Revision: https://phabricator.services.mozilla.com/D29928 --HG-- extra : rebase_source : 468b1124eb11b379b11c041c2ea97f6d5b46fe52 extra : source : 9cdb06fa51891f31c4371b3d06d8e46148b5237a

…erification. r=zombie a=lizzard CLOSED TREE Users who are affected by the intermediate add-on signing certificate expiry need their add-on signatures re-verified as soon as possible after updating to a version containging the fix. A database rebuild includes signature reverifications, so a schema version achieves this. Differential Revision: https://phabricator.services.mozilla.com/D29930 --HG-- extra : rebase_source : 421fe35aaf00d24fa2d79ebcc7dd2c749e1c1280

…for causing bug 1548990. CLOSED TREE

…010). a=sylvestre CLOSED TREE

This patch relies on a schema bump in a previous commit to be effective for users. Differential Revision: https://phabricator.services.mozilla.com/D29940 --HG-- extra : histedit_source : fa86330bd31d9bbbff2fa97d40abdd4ffbfbddd9

… Activity Stream r=k88hudson Differential Revision: https://phabricator.services.mozilla.com/D29909 --HG-- rename : browser/components/newtab/bin/vendor-react.js => browser/components/newtab/bin/vendor.js extra : moz-landing-system : lando

…nsions database r=kmag a=lizzard CLOSED TREE Differential Revision: https://phabricator.services.mozilla.com/D29954 --HG-- extra : amend_source : 0589d26ab75f9036034fb2d9f1e4280acf670b89 extra : histedit_source : fbb56252f19a30dd5c436f9cfe81a2b52ee037dc

…w tree and the document viewer diverge as a result of a call to GetContentSize make sure to invalidate when they converge again because what we draw is changing. r=mattwoodrow The code comment mostly explains things. Differential Revision: https://phabricator.services.mozilla.com/D29953 --HG-- extra : moz-landing-system : lando

--HG-- extra : amend_source : 52d76b0c7fe42a57b90b6effcddb888647107ee1

…bustage

… available a=jcristau CLOSED TREE Bug #: 1549147 Differential Revision: https://phabricator.services.mozilla.com/D29956 --HG-- extra : histedit_source : 83a22fbbbc14d43cb615d6fc0e50199713a38dab

Changes impact theme-twisty icons in the TreeView component: - Make sure theme-twisty uses the selection color (white) in selected rows; but override that style for Network details accordion headers. - Improve the vertical alignment and pixel-perfect icon rendering by making sure the icon element takes the full available height (16px) and avoiding assymetrical padding (affects the rendering of centered background-image, making them blurry on 1x displays). - Tweak the horizontal spacing of theme-twisty icons so that they take up a total of 20px width (similar to what is used in Debugger and Inspector), versus 17px previously. Differential Revision: https://phabricator.services.mozilla.com/D29550 --HG-- extra : moz-landing-system : lando

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

…lc CLOSED TREE Differential Revision: https://phabricator.services.mozilla.com/D29963 --HG-- extra : amend_source : f6cd21d8189ad059bea00e4f4bd373a013d31401

…BC. r=nika This is essentially equal to restoring cached children and removing current children from a BrowsingContext, which is the correct behaviour. It would've been better if the current children were removed in a more transparent manner, but it is more important to remove an assert that too eagerly triggers. Differential Revision: https://phabricator.services.mozilla.com/D29945 --HG-- extra : moz-landing-system : lando

--HG-- extra : amend_source : 787c174982a4fc831ece91fc26fbb95e3b37210a

…P. r=johannh Differential Revision: https://phabricator.services.mozilla.com/D27193 --HG-- extra : moz-landing-system : lando

…r=jmaher Differential Revision: https://phabricator.services.mozilla.com/D29920 --HG-- extra : moz-landing-system : lando

…nt failures r=jmaher Differential Revision: https://phabricator.services.mozilla.com/D29908 --HG-- extra : moz-landing-system : lando

…js and replace with E10S.serializePrincipal. r=ckerschb Differential Revision: https://phabricator.services.mozilla.com/D29958 --HG-- extra : moz-landing-system : lando

Backed out changeset 4352d1f0da34 (bug 1540200) Backed out changeset ff2ca836d8a7 (bug 1540200) Backed out changeset 3e4cc0d312d0 (bug 1540200)

…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

…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

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

…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.

Commits on May 15, 2019

Add Android configuration.

MrAlex94 committed May 15, 2019

Configuration menu

View commit details

Copy full SHA for 926c0e5

Browse repository at this point

Copy the full SHA

926c0e5 View commit details

Browse the repository at this point in the history

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Gecko68 #993

Gecko68 #993

Commits on Apr 26, 2019

Commits on Apr 27, 2019

Commits on Apr 28, 2019

Commits on Apr 29, 2019

Commits on Apr 30, 2019

Commits on May 1, 2019

Commits on May 2, 2019

Commits on May 3, 2019

Commits on May 4, 2019

Commits on May 5, 2019

Commits on May 6, 2019

Commits on May 7, 2019

Commits on May 11, 2019

Commits on May 13, 2019

Commits on May 15, 2019