Update aboutHome.css #2

J0WI · 2014-01-12T13:11:03Z

bug 939428

…joey

Add SourceEventType::BLUETOOTH

@yurenju

======== https://hg.mozilla.org/integration/gaia-central/rev/3c7ae072e684 Author: Kyle Machulis <[email protected]> Desc: Merge pull request #16096 from qdot/969650-move-customization-sample-to-gaia Bug 969650 - Add customization sample to gaia ======== https://hg.mozilla.org/integration/gaia-central/rev/8715b511cbd5 Author: Kyle Machulis <[email protected]> Desc: Bug 969950 - Cleaning up distribution sample ======== https://hg.mozilla.org/integration/gaia-central/rev/de97a5d865ef Author: Kyle Machulis <[email protected]> Desc: Bug 969650 - Subtree merge of yurenju/gaia-distribution-sample ======== https://hg.mozilla.org/integration/gaia-central/rev/eb9ae9a4503f Author: Yuren Ju <[email protected]> Desc: Merge pull request #3 from jds2501/simbookmarks Update SIM bookmark customization to include sample mcc mnc US SIM customization, r=@yurenju ======== https://hg.mozilla.org/integration/gaia-central/rev/705efd9c2fcd Author: jds2501 <[email protected]> Desc: Update SIM bookmark customization to include sample mcc mnc US SIM customization ======== https://hg.mozilla.org/integration/gaia-central/rev/72e64b8de4b1 Author: Yuren Ju <[email protected]> Desc: Merge pull request #2 from KevinGrandon/master Add calendar.json r=yurenju ======== https://hg.mozilla.org/integration/gaia-central/rev/56feb8a57eb1 Author: Kevin Grandon <[email protected]> Desc: Add calendar.json ======== https://hg.mozilla.org/integration/gaia-central/rev/90aef8c4de58 Author: gasolin <[email protected]> Desc: Create README.md ======== https://hg.mozilla.org/integration/gaia-central/rev/8f96ae99b519 Author: Yuren Ju <[email protected]> Desc: Merge pull request #1 from gasolin/patch-1 add runtime customize for bookmark setting, r=yurenju ======== https://hg.mozilla.org/integration/gaia-central/rev/80285b122244 Author: gasolin <[email protected]> Desc: add runtime customize for bookmark setting ======== https://hg.mozilla.org/integration/gaia-central/rev/4e64191b5493 Author: Yuren Ju <[email protected]> Desc: Initial commit

….js to Log.jsm; r=gps,rnewman

…nded, rewrite to Task.jsm; r=unfocused

======== https://hg.mozilla.org/integration/gaia-central/rev/b55d2780462e Author: Etienne Segonzac <[email protected]> Desc: Merge pull request #19261 from etiennesegonzac/bug-986062-edge-reflow-take-2 Bug 986062 edge reflow take 2 r=vingtetun,janx ======== https://hg.mozilla.org/integration/gaia-central/rev/6f5cf42576b3 Author: Etienne Segonzac <[email protected]> Desc: Bug 986062 - Adding an integration test making sure we don't reflow during edge gestures. Take #2. ======== https://hg.mozilla.org/integration/gaia-central/rev/6dec66e2f9eb Author: Arnau <[email protected]> Desc: Merge pull request #19322 from pacorampas/replace-images-dialer-1010129 Bug 1010129 - [Dialer] Replace outdated icons and add missing ones. r=rik ======== https://hg.mozilla.org/integration/gaia-central/rev/c5bf4db8dc3d Author: Paco Rampas <[email protected]> Desc: Bug 1010129 - [Dialer] Replace outdated icons and add missing ones.

…easurement, r=rnewman --HG-- extra : rebase_source : 1c07d8481b8152af39fea889504d4fdfef42da53

…e on windows platform,mozilla#3 code format

…ck, children toggle three times (on click #1, click #2 and dblclick events). Ignore the dblclick on arrow. r=vp

edmorley · 2014-08-19T19:02:56Z

(Mass-PR-close)
This PR is against gecko-dev, which is read only. Did you mean to submit it against another repo?
Changes to repos covered by gecko-dev must be made to the hg.mozilla.org repo, which is then mirrored here. Please see:
https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F

Changes to make group identifiers strings rather than integers

…kyfriedtakahe

…ckyfriedtakahe, a=sledru

… fires, causing orange. r=orange Example stack, from editor/libeditor/tests/browserscope/test_richtext2.html : ###!!! ASSERTION: should only call on first continuation/ib-sibling: 'nsLayoutUtils::IsFirstContinuationOrIBSplitSibling(this)', file /builds/slave/m-in-l64-d-0000000000000000000/build/src/layout/base/../generic/nsIFrame.h, line 875 #01: AdjustAppendParentForAfterContent [layout/base/nsCSSFrameConstructor.cpp:6059] #2: nsCSSFrameConstructor::ContentAppended(nsIContent*, nsIContent*, bool) [layout/base/nsCSSFrameConstructor.cpp:7155] #3: PresShell::ContentAppended(nsIDocument*, nsIContent*, nsIContent*, int) [layout/base/nsPresShell.cpp:4520] #4: nsNodeUtils::ContentAppended(nsIContent*, nsIContent*, int) [dom/base/nsNodeUtils.cpp:132] #5: nsINode::doInsertChildAt(nsIContent*, unsigned int, bool, nsAttrAndChildArray&) [dom/base/nsINode.cpp:1544] #6: nsINode::ReplaceOrInsertBefore(bool, nsINode*, nsINode*, mozilla::ErrorResult&) [dom/base/nsINode.cpp:2209] #7: mozilla::dom::NodeBinding::appendChild [obj-firefox/dom/bindings/NodeBinding.cpp:600]

Use the system NSS CA trust library

…function-decl that happens to provide inline impl, in FakeInputPortService.cpp. rs=froydnj

…ical Otherwise we can get a crash with the following stack: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 14711] 0x5d99974e in mozilla::gl::GLContext::BeforeGLCall (this=0x6dbf0800, funcName=0x60f251a4 <mozilla::gl::GLContext::raw_fDeleteProgram(unsigned int)::__PRETTY_FUNCTION__> "void mozilla::gl::GLContext::raw_fDeleteProgram(GLuint)") at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:683 683 MOZ_ASSERT(IsCurrent()); (gdb) where #0 0x5d99974e in mozilla::gl::GLContext::BeforeGLCall (this=0x6dbf0800, funcName=0x60f251a4 <mozilla::gl::GLContext::raw_fDeleteProgram(unsigned int)::__PRETTY_FUNCTION__> "void mozilla::gl::GLContext::raw_fDeleteProgram(GLuint)") at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:683 #1 0x5d99bed6 in mozilla::gl::GLContext::raw_fDeleteProgram (this=0x6dbf0800, program=210003) at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:2232 #2 0x5d99c10a in mozilla::gl::GLContext::fDeleteProgram (this=0x6dbf0800, program=210003) at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:2270 #3 0x5daa0ae6 in mozilla::layers::ShaderProgramOGL::~ShaderProgramOGL (this=0x6d7df000, __in_chrg=<optimized out>) at /home/roc/mozilla-inbound/gfx/layers/opengl/OGLShaderProgram.cpp:491 #4 0x5da86bdc in mozilla::layers::CompositorOGL::CleanupResources (this=0x67ae4d70) at /home/roc/mozilla-inbound/gfx/layers/opengl/CompositorOGL.cpp:177 --HG-- extra : commitid : LPnSogXNNio extra : rebase_source : 0564dd5688916271c4a709ae6f15ba7ad493a761

======== https://hg.mozilla.org/integration/gaia-central/rev/20db0a074a97 Author: Johan Lorenzo <[email protected]> Desc: Merge pull request #31611 from JohanLorenzo/bug-1196717 Bug 1196717 - Dogfood test - Delete thread in SMS ======== https://hg.mozilla.org/integration/gaia-central/rev/9c3c875eb3a7 Author: Johan Lorenzo <[email protected]> Desc: Bug 1196717 - Dogfood test - Delete thread in SMS ======== https://hg.mozilla.org/integration/gaia-central/rev/e9b47d1d18c0 Author: Etienne Segonzac <[email protected]> Desc: Merge pull request #31737 from etiennesegonzac/bug-1197738 Bug 1197738 - Take #2, fixing the menu transition without breaking the js engine r=albertopq ======== https://hg.mozilla.org/integration/gaia-central/rev/73e651d429c3 Author: Etienne Segonzac <[email protected]> Desc: Bug 1197738 - Take #2, fixing the menu transition without breaking the js engine ======== https://hg.mozilla.org/integration/gaia-central/rev/dceba3fb6595 Author: Johan Lorenzo <[email protected]> Desc: Merge pull request #31675 from JohanLorenzo/bug-1184511 Bug 1184511 - [Aries] test_settings_device_info fails because only 1 … ======== https://hg.mozilla.org/integration/gaia-central/rev/99ebb8a2a579 Author: Johan Lorenzo <[email protected]> Desc: Bug 1184511 - [Aries] test_settings_device_info fails because only 1 IMEI is displayed

======== https://hg.mozilla.org/integration/gaia-central/rev/20db0a074a97 Author: Johan Lorenzo <[email protected]> Desc: Merge pull request #31611 from JohanLorenzo/bug-1196717 Bug 1196717 - Dogfood test - Delete thread in SMS ======== https://hg.mozilla.org/integration/gaia-central/rev/9c3c875eb3a7 Author: Johan Lorenzo <[email protected]> Desc: Bug 1196717 - Dogfood test - Delete thread in SMS ======== https://hg.mozilla.org/integration/gaia-central/rev/e9b47d1d18c0 Author: Etienne Segonzac <[email protected]> Desc: Merge pull request #31737 from etiennesegonzac/bug-1197738 Bug 1197738 - Take mozilla#2, fixing the menu transition without breaking the js engine r=albertopq ======== https://hg.mozilla.org/integration/gaia-central/rev/73e651d429c3 Author: Etienne Segonzac <[email protected]> Desc: Bug 1197738 - Take mozilla#2, fixing the menu transition without breaking the js engine ======== https://hg.mozilla.org/integration/gaia-central/rev/dceba3fb6595 Author: Johan Lorenzo <[email protected]> Desc: Merge pull request #31675 from JohanLorenzo/bug-1184511 Bug 1184511 - [Aries] test_settings_device_info fails because only 1 … ======== https://hg.mozilla.org/integration/gaia-central/rev/99ebb8a2a579 Author: Johan Lorenzo <[email protected]> Desc: Bug 1184511 - [Aries] test_settings_device_info fails because only 1 IMEI is displayed

Implement fopen/fclose Make it not crash on destructor Add stat/lstat Feedback from baku IPC from worker -> main thread, wip Revert "IPC from worker -> main thread, wip" This reverts commit 9227276. Background channel for OS module Fopen on main thread, add fread Implement open,read,close. WIP doing stat operations on the main thread Serialize stat over IPC, and run lstat on main thread Use FileDescriptor in IPC Remove OsManager::Constructor Error handling Add a test that runs in a mozbrowser remote iframe Little bit of cleanup Rename OsManagerFile to OsManagerFd in webidl, and add list of missing methods (based on emscripten's fs modules) Begin implementing VerifyRights Add chmod, fchmod, unlink Add utime, lutime, futime Feedback from baku mozilla#2 Mark fields in OsManager.webidl as constant A test that runs in an app Add truncate, ftruncate, mkdir, rmdir Change ok() to is() calls in dom/os/test Add rename Add readdir. Change NS_LossyConvertUTF16toASCII to ToNewCString in OsFileChannel. Add symlink, readlink Rename Retval to RetVal everywhere mOsManager was not cached between requests to it, now it is Get list of paths for os from manifest Communication from worker->main->worker->background Add actual path checking, expand TEMPDIR if found in manifest Fix permissions threading Test running against new permission system Clean up Remove printf statement in dom/bindings/Date feedback #1 Rewrite VerifyRights string handlign More feedback from baku Comments from baku Feedback Baku #85 Fix le build again

======== https://hg.mozilla.org/integration/gaia-central/rev/670bb87fcd72 Author: Johan Lorenzo <[email protected]> Desc: Merge pull request #33605 from JohanLorenzo/bug-1230099 Bug 1230099 - Delete tests already ported to Gij - round #2 ======== https://hg.mozilla.org/integration/gaia-central/rev/437631e3f8f6 Author: Johan Lorenzo <[email protected]> Desc: Bug 1230099 - Delete tests already ported to Gij - round #2

Bug 1197749 - Add RemoteControlService for remote control feature; a=jocheng

Modify the devtools autocomplete-popup to rely on a HTMLTooltip instance instead of a XUL panel. Other than the straightforward migration to HTML, the main difference with the new implementation is that the richlistbox has now been replace with a simple HTML list element. The former XUL widget used to be able to take the focus from the input it was linked to. This is no longer the case. Most autocomplete users were always keeping the focus in the input, except for the inspector-search, which was moving the focus back and forth between the input and the autocomplete's richlistbox. Now the focus is always in the input. A practical example to illustrate how this changes the UX: before when the user had the focus on the first element of the list, pressing "DOWN" would keep the element selected but visually move the focus in the input. Now the selection simply cycles to the next item. Even though this introduces a difference in behaviour compared to the previous implementation, it makes the inspector search UX consistent with the other autocomplete widgets used in devtools. Another difference is about the display for the inspector-search. The position of the autocomplete popup used to be above the input. This is now impossible to achieve because the search input is at the top of the toolbox and the HTML tooltip can not exceed the limits of the toolbox. For this #2 issue, either we manage to use XUL panel wrappers, in which case, the autocomplete will be displayed as it used to. Or we can invert the order in which items are inserted and explicitly ask for the autocomplete to be displayed below the input. I prefered not to change this here in order to make the code change easier to understand, but it should be addressed in a follow-up. MozReview-Commit-ID: jH9aXm9Jvz --HG-- extra : rebase_source : 57267be0d214ed807f3152838c4123400ab7b7e3

```js let lastDequeueSize = Infinity; decoder.ondequeue = () => { assert_greater_than(lastDequeueSize, 0, "Dequeue event after queue empty"); assert_greater_than(lastDequeueSize, decoder.decodeQueueSize, "Dequeue event without decreased queue size"); lastDequeueSize = decoder.decodeQueueSize; }; ``` The above checkes doesn't really work since the VideoDecoder's codec-work-queue runs in parallel with the VideoDecoder interface. The dequeue events can arrive after the last dequeue size has been 0 if the work queue decodes multiple samples while VideoDecoder is processing just one dequeue event. Besides, `decodeQueueSize` can change between the two `decoder.decodeQueueSize` calls since it can be mutated on both VideoDecoder's owner thread and the codec-work-queue thread. As a result, these two `decodeQueueSize` can be different, and the `lastDequeueSize` is not guaranteed to be decreased one at a time per event, even if the internal decodeQueueSize is decreased one at a time (on codec-work-queue thread). The value can be decreased more than one at a time. The following example demonstrates one case when those checks can fail. Suppose VideoDecoder *D* runs on thread *T* (main or worker) and codec-work-queue runs on thread *Q*. In the test, by the time VideoDecoder is `configure`d successfully and `decode` request are sent, the codec-work-queue is ready to `decode` the pending samples. Below illustrates why the wpt checks in the begining don't work Q) The underlying codec is configured, ready to decode sample #1. Schedule a dequeue event. The current queue size is 9. T) Get a dequeue event #1. Now D.decodeQueueSize is 9. Q) Decode sample #1 succeeded, ready to decode sample mozilla#2. Schedule a dequeue event. The current queue size is 8. T) `D.decode()` for sample #1 succeeded. Get VideoFrame #1. T) Get a dequeue event mozilla#2. Now D.decodeQueueSize is 8. Q) Decode sample mozilla#2 succeeded, ready to decode sample mozilla#3. Schedule a dequeue event. The current queue size is 7. T) `D.decode()` for sample mozilla#2 succeeded. Get VideoFrame mozilla#2. Q) Decode sample mozilla#3 succeeded, ready to decode sample mozilla#4. Schedule a dequeue event. The current queue size is 6. Q) Decode sample mozilla#4 succeeded, ready to decode sample mozilla#5. Schedule a dequeue event. The current queue size is 5. T) Get a dequeue event mozilla#3. Now D.decodeQueueSize is 5. T) `D.decode()` for sample mozilla#3 succeeded. Get VideoFrame mozilla#3. T) Get a dequeue event mozilla#4. Now D.decodeQueueSize is 5. => "Dequeue event without decreased queue size" fails here Q) Decode sample mozilla#5 succeeded, ready to decode sample mozilla#6. Schedule a dequeue event. The current queue size is 4. Q) Decode sample mozilla#6 succeeded, ready to decode sample mozilla#7. Schedule a dequeue event. The current queue size is 3. Q) Decode sample mozilla#7 succeeded, ready to decode sample mozilla#8. Schedule a dequeue event. The current queue size is 2. T) `D.decode()` for sample mozilla#4 succeeded. Get VideoFrame mozilla#4. T) Get a dequeue event mozilla#5. Now D.decodeQueueSize is 2. T) `D.decode()` for sample mozilla#5 succeeded. Get VideoFrame mozilla#5. T) Get a dequeue event mozilla#6. Now D.decodeQueueSize is 2. => "Dequeue event without decreased queue size" fails again here Q) Decode sample mozilla#8 succeeded, ready to decode sample mozilla#9. Schedule a dequeue event. The current queue size is 1. T) `D.decode()` for sample mozilla#6 succeeded. Get VideoFrame mozilla#6. Q) Decode sample mozilla#9 succeeded, ready to decode sample mozilla#10. Schedule a dequeue event. The current queue size is 0. T) Get a dequeue event mozilla#7. Now D.decodeQueueSize is 0. T) `D.decode()` for sample mozilla#7 succeeded. Get VideoFrame mozilla#7. T) Get a dequeue event mozilla#8. D.decodeQueueSize is still 0. => "Dequeue event after queue empty" fails here => "Dequeue event without decreased queue size" fails here as well In brief, what VideoDecoder can guarantee are the order of dequeue event, decode() result, and the flush() result: 1. For sample #N, its dequeue event arrives before it's decode() callback 2. The results/callbacks of decode() and flush() are arrived in FIFO order There is no guarantee that `decodeQueueSize` read on the VideoDecoder's owner thread only decrease one per dequeue event. If the codec-work-queue decodes sample #1, mozilla#2, ... , #K while the dequeue event for sample #1 is being dispatched to or handled on the VideoDecoder's owner thread, the last-dequeueQueueSize can drop more than one compared to it's previous value, and for the same reason, the dequeue event can arrive even if the last-dequeueQueueSize has been set to 0. Differential Revision: https://phabricator.services.mozilla.com/D179514 Depends on D177212

The WPTs assume the error callback invoked via the decode() failure will arrive before flush()'s promise, but it's not guaranteed. The example below demonstrates why this assumption isn't held. Suppose VideoDecoder *D* runs on thread *T* (main or worker) and codec-work-queue runs on thread *Q*. In the test, by the time VideoDecoder is `configure`d successfully and `decode` request are sent, the codec-work-queue is ready to `decode` the pending samples. Below illustrates that error callback can arrive after flush()'s promise. Q) The underlying codec is configured, ready to decode sample #1. Q) Decode sample #1 succeeded, ready to decode sample mozilla#2. T) `D.decode()` for sample #1 succeeded. Get VideoFrame #1. Q) Decode sample #1 failed, ready to flush the decoder. T) `D.decode()` for sample mozilla#2 failed. Close `D` via `close()` with an `EncodingError`. The `close` queues a task to invoke the error callback. Q) Flush has been done. T) `D.flush()` has done (but `D` has been closed) and its promise get rejected => error callback hasn't arrive yet! T) The error callback scheduled by `close` above is called Differential Revision: https://phabricator.services.mozilla.com/D179515 Depends on D179514

We already cherry-picked this when we vendored be03c09718. Upstream commit: https://webrtc.googlesource.com/src/+/d75b9e9ff07ee42841b4e416629c9fbd4b058905 [M112] Revert "Only serialize non-stopped RTP header extensions" This reverts commit be03c0971863c9e6807fcbdb4175754e8242a652. Causes regression in web projects that 1/ add a stopped-by-default extension in SRD 2/ call createAnswer 3/ munge the stopped-by-default extension back in SLD 4/ create a subsequent offer and expect the extension to be present BUG=chromium:1427442,chromium:1051821 Change-Id: I2e48831e92384963a254d873398f54eaee96739a Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299143 Reviewed-by: Harald Alvestrand <[email protected]> Commit-Queue: Philipp Hancke <[email protected]> Reviewed-by: Henrik Boström <[email protected]> Cr-Commit-Position: refs/branch-heads/5615@{#2} Cr-Branched-From: cdfeb4f7922f05007d88c8263842998ec79b6dd6-refs/heads/main@{#39376}

…e DOM tree in each time of the loop r=m_kato There are 2 possible scenarios which are not handled by the method. 1. Moving content node to new `<blockquote>` has already been moved to outside of the editing host. 2. There is no container to insert new `<blockquote>`, e.g., in an inline editing host. In the case #1, we should ignore the ex-child node. In the case #2, we should abort it. Note that Chrome inserts `<blockquote>` even if there is no proper container. However, such behavior is disagreed in interop-2023. Therefore, it's okay just to abort it for now. Depends on D180781 Differential Revision: https://phabricator.services.mozilla.com/D180782

…ding error in page.py test, a=testonly Automatic update from web-platform-tests [wdspec] browsingContext.print: fix rounding error in page.py test (#40504) * [wdspec] browsingContext.print: fix rounding error in page.py test [pytest](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/webdriver/tests/support/image.py) uses: def cm_to_px(cm): return round(cm * 96 / 2.54) [js](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/tools/wptrunner/wptrunner/print_pdf_runner.html) uses: const viewport = page.getViewport({ scale: 96. / 72. }); ... canvas.height = viewport.height; canvas.width = viewport.width; This produces a rounding error, even though the dimension is correct: > assert cm_to_px(expected_dimensions["height"]) == height E assert 454 == 453 E +454 E -453 The inconsistency of rounding in both ends becomes clear when we eliminate "round" in the pytest side: > assert cm_to_px(expected_dimensions["height"]) == height E assert 453.54330708661416 == 453 E +453.54330708661416 E -453 There are multiple ways to fix this issue. Option #1: Use "floor" instead of "round" in pytest. Option #2: Use a range in the assertion comparison, allowing a difference of up to +-1.0. This is what this PR does. The comparison is performed in [`assert_pdf_dimensions`](https://github.com/web-platform-tests/wpt/blob/b6107cc1ac8b9c2800b4c8e58af719b8e4d9b8db/webdriver/tests/support/fixtures_bidi.py#L210). The problematic part is .96 / .72 which evaluates to 4/3 = 1.333333.... * use floor in cm_to_px instead of round * compare to floor and to round instead of a range * Revert "compare to floor and to round instead of a range" This reverts commit 63f894e6d1881616e0f13b7a40ddcb30b772eba8. * Revert "use floor in cm_to_px instead of round" This reverts commit 7e65d918b25575060ca50009d261d1e76dca6cae. -- wpt-commits: fb57353809aa19c0659ece5563d05ed20706d1fc wpt-pr: 40504

Upstream commit: https://webrtc.googlesource.com/src/+/2a256c82ecb7cd4c797d834d49051bc2bf79986c Implement support for Chrome task origin tracing. #2/4 This prepares TaskQueueBase sub classes to be able to migrate to the location and traits-based API. It re-introduces a Location class into the webrtc namespace, which is meant to be overridden by Chromium. Bug: chromium:1416199 Change-Id: I712c7806a71b3b99b2a2bf95e555b357c21c15ae Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294381 Reviewed-by: Mirko Bonadei <[email protected]> Commit-Queue: Markus Handell <[email protected]> Reviewed-by: Danil Chapovalov <[email protected]> Reviewed-by: Harald Alvestrand <[email protected]> Cr-Commit-Position: refs/heads/main@{#39400}

Upstream commit: https://webrtc.googlesource.com/src/+/ecab2a49da48f0279a3b6422dab602614630005e [m114] Attempt to recycle a stopped data m-line before creating a new one which avoids an infinitely growing SDP if the remote end rejects the datachannel section. This will reactivate the m-line even if all datachannels are closed. BUG=chromium:1442604 (cherry picked from commit 522380ff734174faab694e1b67c9d20fffa8738e) No-Try: True Change-Id: If60f93b406271163df692d96102baab701923602 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304241 Reviewed-by: Harald Alvestrand <[email protected]> Commit-Queue: Philipp Hancke <[email protected]> Reviewed-by: Henrik Boström <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#40029} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305420 Commit-Queue: Harald Alvestrand <[email protected]> Reviewed-by: Mirko Bonadei <[email protected]> Cr-Commit-Position: refs/branch-heads/5735@{#2} Cr-Branched-From: df7df199abd619e75b9f1d9a7e12fc3f3f748775-refs/heads/main@{#39949}

We already cherry-picked this when we vendored e46e37b6f8. Upstream commit: https://webrtc.googlesource.com/src/+/ba943f71e64a93558a51e75d18917f363b8672e9 [M115] Move transceiver iteration loop over to the signaling thread. This is required for ReportTransportStats since iterating over the transceiver list from the network thread is not safe. (cherry picked from commit dba22d31909298161318e00d43a80cdb0abc940f) Bug: chromium:1446274, webrtc:12692 Change-Id: I7c514df9f029112c4b1da85826af91217850fb26 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/307340 Reviewed-by: Harald Alvestrand <[email protected]> Commit-Queue: Tomas Gunnarsson <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#40197} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308000 Reviewed-by: Mirko Bonadei <[email protected]> Cr-Commit-Position: refs/branch-heads/5790@{#2} Cr-Branched-From: 2eacbbc03a4a41ea658661225eb1c8fc07884c33-refs/heads/main@{#40122}

…g anchor element's siblings, a=testonly Automatic update from web-platform-tests Fix :has() invalidation bug when removing anchor element's siblings This CL fixes a :has() invalidation bug when the following conditions are met: 1. A style rule uses a :has() pseudo class. The :has() test result is affected by the anchor element's relationship to its sibling element at fixed distance. (e.g. '.a:has(+ .b) {}') 2. The :has() pseudo class was tested on an anchor element and it didn't matched. 3. If a sibling of the anchor element is removed, the :has() will match the anchor element. (e.g. '<div class=a></div><div id=target></div><div class=b></div>') 4. Remove a sibling of the anchor element so that the :has() matches the anchor element. (e.g. 'target.remove();') For the removal, StyleEngine have to schedule :has() invalidation even if the removed element doesn't have any identifier stored in RuleFeatureSet. But it is not efficient to schedule :has() invalidation for every element removal. To avoid unnecessary :has() invalidation, StyleEngine checks whether its parent has the 'ChildrenAffectedByDirectAdjacentRules' flag set or not. Currently, the SelectorChecker sets the flag only when it consumes a direct adjacent combinator(+). This works most cases but it doesn't work in this case (condition #2) because the SelectorChecker stops the :has() argument selector matching before consuming the direct adjacent combinator. Due to this, the parent of the anchor element doesn't have the 'ChildrenAffectedByDirectAdjacentRules' flag set and the StyleEngine doesn't schedule the :has() invalidation for the removal. To fix the error, when the SelectorChecker tests a :has() pseudo class on an anchor element and the :has() is affected by the anchor element's relationship to a sibling at fixed distance, the SelectorChecker sets the flag of the parent to indicate that StyleEngine need to schedule :has() invalidation whenever any child of the element is removed. Bug: 1480643 Change-Id: I5ec2e3c1db2773020368415f68bca1503367e669 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4864627 Commit-Queue: Byungwoo Lee <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1198137} -- wpt-commits: 2f5741f704e062180e3424c1126ba5b30cf6dd07 wpt-pr: 42012

Upstream commit: https://webrtc.googlesource.com/src/+/279a05475d3bdc90ecbe4ba03a640411562b8626 [M116] In VideoCaptureImpl and subclasses add thread and lock annotations This annotates all unannotated members in VideoCaptureImpl and its subclasses with either of: - api_checker_: access on the api thread only - capture_checker_: access in callbacks/on the capture thread while capture is active, on the api thread otherwise - a Mutex if it is already protected by it (cherry picked from commit eee10391cac9c63be3ec6c6b6fe0a8b097c859b1) Bug: webrtc:15181 Change-Id: I5084e7752a4716c29b85a9b403a88696f66d811f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305647 Commit-Queue: Ilya Nikolaevskiy <[email protected]> Reviewed-by: Ilya Nikolaevskiy <[email protected]> Reviewed-by: Per Kjellander <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#40335} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310500 Reviewed-by: Henrik Boström <[email protected]> Cr-Commit-Position: refs/branch-heads/5845@{#2} Cr-Branched-From: f80cf814353d11a9f22bef5ce5e8868f2c72f0d0-refs/heads/main@{#40319}

We already cherry-picked this when we vendored 402f60c2ea. Upstream commit: https://webrtc.googlesource.com/src/+/70aa7e99e4af06e9a2273793179dfcfddad11898 [Merge to 117] CHECK against overwrites in send_modules_map_ (cherry picked from commit 9d8fb97b3ca56ec9920271d8e545ae2ac76b143c) No-try: true Bug: chromium:1477075 Change-Id: Ia05a868bfab9e99ef66704e8d6bce516a7a43b0a Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318440 Reviewed-by: Sergey Silkin <[email protected]> Commit-Queue: Harald Alvestrand <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#40673} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/319100 Reviewed-by: Taylor Brandstetter <[email protected]> Cr-Commit-Position: refs/branch-heads/5938@{#2} Cr-Branched-From: 82e5f91a2bdf955aa870142008fbdc9ac12f6acd-refs/heads/main@{#40524}

…chevobbe Just starting up a debug build you will get 40 copies of this printed. The uri that we fail to get host of is about:newtab. One stack looks like this #2: mozilla::BasePrincipal::GetIsLoopbackHost(bool*) #3: mozilla::net::LoadInfo::LoadInfo(nsIPrincipal*, nsIPrincipal*, nsINode*, unsigned int, nsIContentPolicy::nsContentPolicyType, mozilla::Maybe<mozilla::dom::ClientInfo> const&, mozilla::Maybe<mozilla::dom::ServiceWorkerDescriptor> const&, unsigned int, bool #4: ShouldLoadCachedImage(imgRequest*, mozilla::dom::Document*, nsIPrincipal*, nsIContentPolicy::nsContentPolicyType, bool) #5: imgLoader::LoadImage(nsIURI*, nsIURI*, nsIReferrerInfo*, nsIPrincipal*, unsigned long long, nsILoadGroup*, imgINotificationObserver*, nsINode*, mozilla::dom::Document*, unsigned int, nsISupports*, nsIContentPolicy::nsContentPolicyType, nsTSubstring<char16 #6: nsContentUtils::LoadImage(nsIURI*, nsINode*, mozilla::dom::Document*, nsIPrincipal*, unsigned long long, nsIReferrerInfo*, imgINotificationObserver*, int, nsTSubstring<char16_t> const&, imgRequestProxy**, nsIContentPolicy::nsContentPolicyType, bool, bool, #7: mozilla::css::ImageLoader::LoadImage(mozilla::StyleComputedUrl const&, mozilla::dom::Document&) #8: mozilla::StyleComputedUrl::ResolveImage(mozilla::dom::Document&, mozilla::StyleComputedUrl const*) #9: nsStyleImageLayers::ResolveImages(mozilla::dom::Document&, nsStyleImageLayers const*) #10: mozilla::ComputedStyle::StartImageLoads(mozilla::dom::Document&, mozilla::ComputedStyle const*) Differential Revision: https://phabricator.services.mozilla.com/D193349

Upstream commit: https://webrtc.googlesource.com/src/+/597e7ba370a973f64f822aa247cb2355de7c5f47 [M118] Obfuscate prflx raddr when using mdns BUG=chromium:1478690 (cherry picked from commit a8e3111d8c6622eeb930c32ab7a2e6be51b3d801) Change-Id: I7a1caad7bbd2fc82507b61b59be71546494a304c Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/319580 Reviewed-by: Harald Alvestrand <[email protected]> Reviewed-by: Henrik Boström <[email protected]> Commit-Queue: Philipp Hancke <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#40724} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320580 Cr-Commit-Position: refs/branch-heads/5993@{#2} Cr-Branched-From: 5afcec093c1403fe9e3872706d04671cbc6d2983-refs/heads/main@{#40703}

Upstream commit: https://webrtc.googlesource.com/src/+/52bc9f7c1205f4b731ea0289b059f7d240c1e228 [Merge M119] Return error when requested codec is preferred but not negotiated Because of our asymmetrical codec situation, it's possible to have send only codecs that we cannot negotiate even with ourselves. This means that we should not have a DCHECK, but just a plain error. (cherry picked from commit 1adea9806d7aec9b5f91181231ccc31fef3b115f) Bug: chromium:1442194, webrtc:15064 Change-Id: I0c170e5c7f356197bcb04bcecb8259c344423ccb Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323183 Reviewed-by: Harald Alvestrand <[email protected]> Commit-Queue: Florent Castelli <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#40939} No-Try: True Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324044 Reviewed-by: Guido Urdaneta <[email protected]> Cr-Commit-Position: refs/branch-heads/6045@{#2} Cr-Branched-From: bce7ce7ba054ac0e79fed49b84ef52fb24c31778-refs/heads/main@{#40854}

…ect> / <embed> as subdocuments. r=longsonr These look like two really old bugs. Part of the issue is that <object> / <embed> manage their frame loader quite differently from <iframe>. This means that we may have a PresShell / ViewManager / etc for a frame loader that doesn't yet have a frame associated. For example, this is the viewport creation for the SVG document that reproduces the problem: #0 0x00005cc60e8302e7 in mozilla::ViewportFrame::SetViewInternal(nsView*) (this=0x68599020, aView=0x683d8f00) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/ViewportFrame.h:106 #1 0x00005cc60e842858 in nsIFrame::SetView(nsView*) (this=0x68599020, aView=0x683d8f00) at /home/emilio/src/moz/gecko/layout/generic/nsFrame.cpp:7057 #2 0x00005cc60e77258a in nsCSSFrameConstructor::ConstructRootFrame() (this=0xc72c715e00) at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:2424 #3 0x00005cc60e7342f5 in mozilla::PresShell::Initialize() (this=0x6830e000) at /home/emilio/src/moz/gecko/layout/base/PresShell.cpp:1758 #4 0x00005cc60c9fb02a in nsContentSink::StartLayout(bool) (this=<optimized out>, aIgnorePendingSheets=<optimized out>) at /home/emilio/src/moz/gecko/dom/base/nsContentSink.cpp:1160 #5 0x00005cc60e2c1581 in nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, unsigned int, bool) (this=<optimized out>, aName=<optimized out>, aAtts=0x6fde8200, aAttsCount=<optimized out>, aLineNumber=3, aColumnNumber=<optimized out>, aInterruptable=true) at /home/emilio/src/moz/gecko/dom/xml/nsXMLContentSink.cpp:982 #6 0x00005cc60e2c17d7 in non-virtual thunk to nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, unsigned int) () at /home/emilio/src/moz/gecko/dom/xml/nsXMLContentSink.cpp:889 #7 0x00005cc60c360307 in nsExpatDriver::HandleStartElement(void*, char16_t const*, char16_t const**) (aUserData=0x224f650d0cc0, aName=0x685aef20 u"http://www.w3.org/2000/svg\xffffdesc", aAtts=0x6fde8200) at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:293 #8 0x00005cc60ee91cea in doContent (parser=0xc72c70f800, startTagLevel=0, enc=<optimized out>, s=<optimized out>, end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, nextPtr=0x7ffca2653288, haveMore=1 '\001') at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:2872 #9 0x00005cc60ee90059 in contentProcessor (parser=0xc72c70f800, start=0xffffffe6 <error: Cannot access memory at address 0xffffffe6>, end=0xc72c511360 "", endPtr=0x1) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:2528 #10 0x00005cc60ee8f8d5 in doProlog (parser=<optimized out>, enc=0x5cc612ce0930 <little2_encoding_ns>, s=0x5bbd31ab508e "<", end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, tok=<optimized out>, next=<optimized out>, nextPtr=0x7ffca2653288, haveMore=1 '\001', allowClosingDoctype=1 '\001') at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:4591 #11 0x00005cc60ee8d86e in prologProcessor (parser=0xc72c70f800, s=0x5bbd31ab5020 "<", end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, nextPtr=0x7ffca2653288) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:4311 #12 0x00005cc60ee8cf45 in MOZ_XML_Parse (parser=0xc72c70f800, s=0x5bbd31ab5020 "<", len=262144, isFinal=0) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:1894 #13 0x00005cc60c3627bc in nsExpatDriver::ParseBuffer(char16_t const*, unsigned int, bool, unsigned int*) (this=0x224f650d0cc0, aBuffer=0x5bbd31ab5020 u"<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<svg height=\"2970\" width=\"2100\" viewBox=\"0 0 2100 2970\" version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlin"..., aLength=131072, aIsFinal=false, aConsumed=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:875 #14 0x00005cc60c362c91 in nsExpatDriver::ConsumeToken(nsScanner&, bool&) (this=<optimized out>, aScanner=..., aFlushTokens=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:970 #15 0x00005cc60c3666a8 in nsParser::Tokenize(bool) (this=0x224f65038e80, aIsFinalChunk=false) at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:1410 #16 0x00005cc60c36595e in nsParser::ResumeParse(bool, bool, bool) (this=0x224f65038e80, allowIteration=true, aIsFinalChunk=false, aCanInterrupt=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:961 #17 0x00005cc60c366c86 in nsParser::OnDataAvailable(nsIRequest*, nsIInputStream*, unsigned long, unsigned int) (this=0x224f65038e80, request=<optimized out>, pIStream=0x6fdfc430, sourceOffset=<optimized out>, aLength=131072) at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:1317 #18 0x00005cc60c897cc2 in nsObjectLoadingContent::OnDataAvailable(nsIRequest*, nsIInputStream*, unsigned long, unsigned int) (this=<optimized out>, aRequest=0x68483080, aInputStream=0x6fdfc430, aOffset=0, aCount=131072) at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:1055 #19 0x00005cc60b9d18f8 in mozilla::net::HttpChannelChild::DoOnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long, unsigned int) (this=0x68483000, aRequest=0x68483080, aContext=<optimized out>, aStream=0x6fdfc430, aOffset=0, aCount=743510880) at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:968 #20 0x00005cc60b9d5cbf in mozilla::net::HttpChannelChild::OnTransportAndData(nsresult const&, nsresult const&, unsigned long const&, unsigned int const&, nsTString<char> const&) (this=0x68483000, aChannelStatus=<optimized out>, aTransportStatus=@0x683be5bc: -2142568440, aOffset=<optimized out>, aCount=<optimized out>, aData=...) at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:867 #21 0x00005cc60badb535 in mozilla::net::ChannelEventQueue::FlushQueue() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/netwerk/ipc/ChannelEventQueue.cpp:90 #22 0x00005cc60b976fda in mozilla::net::ChannelEventQueue::MaybeFlushQueue() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/net/ChannelEventQueue.h:350 #23 0x00005cc60baec442 in mozilla::net::ChannelEventQueue::CompleteResume() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/net/ChannelEventQueue.h:329 #24 mozilla::net::ChannelEventQueue::ResumeInternal()::CompleteResumeRunnable::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/ipc/ChannelEventQueue.cpp:148 #25 0x00005cc60b53d4f1 in mozilla::SchedulerGroup::Runnable::Run() (this=0x685b0200) at /home/emilio/src/moz/gecko/xpcom/threads/SchedulerGroup.cpp:282 #26 0x00005cc60b54ff80 in nsThread::ProcessNextEvent(bool, bool*) (this=0x3dd7f4f3020, aMayWait=<optimized out>, aResult=0x7ffca2653ea7) at /home/emilio/src/moz/gecko/xpcom/threads/nsThread.cpp:1220 #27 0x00005cc60b552f0d in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x68599020, aMayWait=true) at /home/emilio/src/moz/gecko/xpcom/threads/nsThreadUtils.cpp:481 The parent view may not be set properly if the frame is not current by the time it is created. For example in this case the parent for the root view is non-null and comes from the following MakeWindow call: #0 nsDocumentViewer::MakeWindow(nsSize const&, nsView*) (this=0xc72ca72cd0, aSize=..., aContainerView=0x683ba500) at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:2368 #1 0x00005cc60e789b50 in nsDocumentViewer::InitInternal(nsIWidget*, nsISupports*, mozilla::dom::WindowGlobalChild*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, bool, bool, bool) (this=0xc72ca72cd0, aParentWidget=<optimized out>, aState=0x0, aActor=0x0, aBounds=..., aDoCreation=true, aNeedMakeCX=<optimized out>, aForceSetNewDocument=<optimized out>) at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:933 #2 0x00005cc60e789959 in nsDocumentViewer::Init(nsIWidget*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::dom::WindowGlobalChild*) (this=0xc72ca72cd0, aParentWidget=0x7ffca2651020, aBounds=..., aActor=0x7f6216725c00) at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:762 #3 0x00005cc60f4f584f in nsDocShell::SetupNewViewer(nsIContentViewer*, mozilla::dom::WindowGlobalChild*) (this=0x684db000, aNewViewer=<optimized out>, aWindowActor=<optimized out>) at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:8017 #4 0x00005cc60f4f5204 in nsDocShell::Embed(nsIContentViewer*, mozilla::dom::WindowGlobalChild*) (this=0x684db000, aContentViewer=0x7ffca2651020, aWindowActor=0x683ba500) at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:5745 #5 0x00005cc60f4dbc7b in nsDocShell::CreateContentViewer(nsTSubstring<char> const&, nsIRequest*, nsIStreamListener**) (this=0x684db000, aContentType=..., aRequest=0x68483080, aContentHandler=<optimized out>) at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:7819 #6 0x00005cc60f4dab99 in nsDSURIContentListener::DoContent(nsTSubstring<char> const&, bool, nsIRequest*, nsIStreamListener**, bool*) (this=0x683056a0, aContentType=..., aIsContentPreferred=<optimized out>, aRequest=0x68483080, aContentHandler=0xc72c5e8608, aAbortProcess=0x7ffca265139f) at /home/emilio/src/moz/gecko/docshell/base/nsDSURIContentListener.cpp:181 #7 0x00005cc60c2fd8f5 in nsDocumentOpenInfo::TryContentListener(nsIURIContentListener*, nsIChannel*) (this=0xc72c5e85e0, aListener=0x683056a0, aChannel=<optimized out>) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:632 #8 0x00005cc60c2fccd1 in nsDocumentOpenInfo::DispatchContent(nsIRequest*, nsISupports*) (this=0xc72c5e85e0, request=0x68483080, aCtxt=<optimized out>) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:313 #9 0x00005cc60c2fc5aa in nsDocumentOpenInfo::OnStartRequest(nsIRequest*) (this=<optimized out>, request=0x68483080) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:191 #10 0x00005cc60c8975c4 in nsObjectLoadingContent::LoadObject(bool, bool, nsIRequest*) (this=0x4b1b3938b6a8, aNotify=<optimized out>, aForceLoad=<optimized out>, aLoadingChannel=0x68483080) at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:2218 #11 0x00005cc60c89681f in nsObjectLoadingContent::OnStartRequest(nsIRequest*) (this=0x4b1b3938b6a8, aRequest=0x68483080) at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:1006 #12 0x00005cc60b9d1020 in mozilla::net::HttpChannelChild::DoOnStartRequest(nsIRequest*, nsISupports*) (this=0x68483000, aRequest=0x68483080, aContext=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:708 #13 0x00005cc60b9d481b in mozilla::net::HttpChannelChild::OnStartRequest(nsresult const&, mozilla::net::nsHttpResponseHead const&, bool const&, mozilla::net::nsHttpHeaderArray const&, mozilla::net::ParentLoadInfoForwarderArgs const&, bool const&, bool const&, bool const&, unsigned long const&, int const&, unsigned int const&, nsTString<char> const&, nsTString<char> const&, mozilla::net::NetAddr const&, mozilla::net::NetAddr const&, unsigned int const&, nsTString<char> const&, long const&, bool const&, bool const&, bool const&, mozilla::net::ResourceTimingStructArgs const&, bool const&, mozilla::Maybe<unsigned int> const&, bool const&, nsILoadInfo::CrossOriginOpenerPolicy const&) However, even though aContainerView is non-null, the view is incorrect, it's the view for the _old_ frame. The view parent/child relationship gets cleared properly in: #1 0x00005cc60e8e82bf in BeginSwapDocShellsForViews (aSibling=0x0) at /home/emilio/src/moz/gecko/layout/generic/nsSubDocumentFrame.cpp:1027 warning: Source file is more recent than executable. #2 0x00005cc60e8e810b in nsSubDocumentFrame::DestroyFrom (this=0x6cd04eaa45a8, aDestructRoot=0x6cd04eaa45a8, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsSubDocumentFrame.cpp:943 #3 0x00005cc60e7b71a3 in nsIFrame::Destroy (this=0x6cd04eaa45a8) at /home/emilio/src/moz/gecko/layout/generic/nsIFrame.h:657 #4 0x00005cc60e80baac in nsBlockFrame::RemoveFrame (this=0x4b1b39362d88, aListID=<optimized out>, aOldFrame=0x6cd04eaa45a8) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:5597 #5 0x00005cc60e8df29f in nsPlaceholderFrame::DestroyFrom (this=0x4b1b39363240, aDestructRoot=0x4b1b39363240, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsPlaceholderFrame.cpp:181 #6 0x00005cc60e80cf19 in nsBlockFrame::DoRemoveFrameInternal (this=<optimized out>, aDeletedFrame=0x0, aFlags=<optimized out>, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:6265 #7 0x00005cc60e82d947 in nsBlockFrame::DoRemoveFrame (this=0x4b1b39362d88, aDeletedFrame=0x683d8f00, aFlags=244338087) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.h:528 #8 0x00005cc60e80ba3a in nsBlockFrame::RemoveFrame (this=0x4b1b39362d88, aListID=<optimized out>, aOldFrame=0x4b1b39363240) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:5581 #9 0x00005cc60e77fd5c in nsCSSFrameConstructor::ContentRemoved (this=<optimized out>, aChild=0x4b1b3938b600, aOldNextSibling=<optimized out>, aFlags=<optimized out>) at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:7583 #10 0x00005cc60e779a35 in nsCSSFrameConstructor::RecreateFramesForContent (this=0x6fdf9800, aContent=0x4b1b3938b600, aInsertionKind=nsCSSFrameConstructor::InsertionKind::Sync) at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:8593 #11 0x00005cc60e751745 in mozilla::RestyleManager::ProcessRestyledFrames (this=<optimized out>, aChangeList=...) at /home/emilio/src/moz/gecko/layout/base/RestyleManager.cpp:1484 But the temporary state is stored in the _old_ frame-loader, so when we create the new frame, we get to nsSubDocumentFrame::Init, and find nothing, and thus go through nsFrameLoader::Show. But we do have a pres-shell, and nsFrameLoader::Show just early-returns then, and thus we end up with a detached pres shell which is not hooked to the view tree and thus not painted... So there are multiple potential fixes. First (this is the approach this patch takes): * Make nsHideViewer not fail to hide a presentation when the frame loader has changed. This is not an issue per se, but leaves stale views / etc living for too long which is not nice. * Fix up the Show() code path to handle this case properly by parenting the pres-shell and initializing the docshell properly. Second potential fix would be to store the temporary state somewhere else than the frame loader (like the element). This may be a less invasive change somehow, but it looks pretty fishy to me, and not particularly better... Terribly sorry about the lack of test-case, but this is racy as crazy and I had a lot of trouble to even reproduce it in a debug build. This needs the PresShell creation for the subdocument to happen right after setting .data on the <object>, but before processing its reframe. Differential Revision: https://phabricator.services.mozilla.com/D69487

…lla#2) * FIDEFE-4623 - Add CSS formatter for converting tokens to light-dark() calls I originally thought we would be able to use a transformer to handle this case, but outputting references causes my transformer to fail. Because of this, I switched to using a custom CSS formatter and adding the variable references in this formatter. Additionally, I also switched over to using config.js instead of config.json using PR FirefoxUX#3 as a starting point. I also changed the design tokens JSON format to fit what I needed for the light-dark formatting. I'll need to consolidate my changes with the changes in PR FirefoxUX#3, but wanted to get this PR updated. * Remove build.js, use css/variables formatter, update tokens structure This removes the build.js file in favor of using config.js (which requires `style-dictionary build` to build our files). I also removed the custom file formatting code in favor of the included css/variables formatter. Lastly, I updated the tokens structure so instead of "darkValue", we use "dark". Most likely the structure of the tokens file will change again, but I'll create a new PR with those proposed changes. * Restore custom file formatting, simplify ref logic. So we can't use the "css/variables" built-in formatter, otherwise we'll lose our light-dark value. I reverted those changes back to the mappedValues loop so that we maintain the light-dark formatting. I additionally sorted the token so that referenced tokens come after the referenced definitions. I don't think we have to do this for CSS, but it does make the generated CSS a little easier to follow in my opinion. * Remove light-dark formatter and replace with transformer. We can greatly simplify the config.js file by doing two things: 1. Use a transformer for dealing with light-dark. 2. In this transformer, modify the original value of the token. By modifying the value of the original token, we are able to take advantage of the built-in css/variables formatting and so we don't need custom CSS file formatting. Additionally, we can use ...StyleDictionary.transformGroup["group_name"] to get the individual transforms of a group. By doing this we can extend an existing group as seen in this patch. * fix eslint error

Upstream commit: https://webrtc.googlesource.com/src/+/9f1e1925f33a8dd0d7b84f805be6d7f15ff28b0e dcsctp: Fix not using iteraters after NackItem OutstandingData::NackItem nacks a chunk, and if that chunk reaches its partial reliability critera, it will abandon the entire message. If that message hasn't been sent in full, a placeholder "end" message is inserted (see https://crbug.com/webrtc/12812). And when the message is inserted, any iterators may be invalidated (if e.g. std::deque would want to grow the deque). So ensure that there are no iterators used after having called NackItem. By changing the interface of NackItem, and not passing an Item, but just the TSN, this is encouraged. NackAll was rewritten as a two-pass algorithm to first collect TSNs, then iterating that list, looking up the items in the second pass (constant complexity). (cherry picked from commit 161d2c84528ec9eb0c19bfb51024bca54353abc4) No-Try: True Bug: chromium:1510364 Change-Id: I5156b6d6a683184f290e71c98f16bc68ea2a562f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331320 Reviewed-by: Harald Alvestrand <[email protected]> Commit-Queue: Victor Boivie <[email protected]> Reviewed-by: Sam Zackrisson <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#41374} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331960 Reviewed-by: Mirko Bonadei <[email protected]> Cr-Commit-Position: refs/branch-heads/6167@{#2} Cr-Branched-From: ece5cb83715dea85617114b6d4e981fdee2623ba-refs/heads/main@{#41315}

…lla#2) * FIDEFE-4623 - Add CSS formatter for converting tokens to light-dark() calls I originally thought we would be able to use a transformer to handle this case, but outputting references causes my transformer to fail. Because of this, I switched to using a custom CSS formatter and adding the variable references in this formatter. Additionally, I also switched over to using config.js instead of config.json using PR FirefoxUX#3 as a starting point. I also changed the design tokens JSON format to fit what I needed for the light-dark formatting. I'll need to consolidate my changes with the changes in PR FirefoxUX#3, but wanted to get this PR updated. * Remove build.js, use css/variables formatter, update tokens structure This removes the build.js file in favor of using config.js (which requires `style-dictionary build` to build our files). I also removed the custom file formatting code in favor of the included css/variables formatter. Lastly, I updated the tokens structure so instead of "darkValue", we use "dark". Most likely the structure of the tokens file will change again, but I'll create a new PR with those proposed changes. * Restore custom file formatting, simplify ref logic. So we can't use the "css/variables" built-in formatter, otherwise we'll lose our light-dark value. I reverted those changes back to the mappedValues loop so that we maintain the light-dark formatting. I additionally sorted the token so that referenced tokens come after the referenced definitions. I don't think we have to do this for CSS, but it does make the generated CSS a little easier to follow in my opinion. * Remove light-dark formatter and replace with transformer. We can greatly simplify the config.js file by doing two things: 1. Use a transformer for dealing with light-dark. 2. In this transformer, modify the original value of the token. By modifying the value of the original token, we are able to take advantage of the built-in css/variables formatting and so we don't need custom CSS file formatting. Additionally, we can use ...StyleDictionary.transformGroup["group_name"] to get the individual transforms of a group. By doing this we can extend an existing group as seen in this patch. * fix eslint error

Upstream commit: https://webrtc.googlesource.com/src/+/45e49ef5371ed67ee3278244248133bf9783d65c [M123] Fix handling of rejected m-lines without transport description A fingerprint should not be required for m-lines which are rejected. BUG=chromium:326493639,webrtc:11066 (cherry picked from commit 845d6bef52ec08dfd9c87d3eff5ae5c07c3fe55d) Change-Id: I7428c91a144ca46650e13d72868f160652a98339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/340322 Reviewed-by: Harald Alvestrand <[email protected]> Reviewed-by: Florent Castelli <[email protected]> Commit-Queue: Philipp Hancke <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#41794} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/341023 Cr-Commit-Position: refs/branch-heads/6312@{#2} Cr-Branched-From: 0355f455a48b141a8277442825ec776a74d66fb7-refs/heads/main@{#41763}

…est is affected by rounded corners, a=testonly Automatic update from web-platform-tests Fall back to main thread if scroll hit test is affected by rounded corners We had two issues: 1. Before we had fast rounded corners, we always created mask layers for rounded corner clips, and the mask layer made the scroll begin unreliable and fall back to the main thread. With fast rounded corners, the scrolls were treated as reliable without checking if the point is in or out of the rounded corners. 2. If the scroller has a rounded corner by itself (instead of from an ancestor), as we only create InnerBorderRadiusClip for the contents, the compositor doesn't actually know which part of the layer bounds is transparent to hit test (e.g. if the scroller has a border which is outside of the InnerBorderRadiusClip). Now with HitTestOpaqueness, such layers have HitTestOpaqueness::kMixed. This CL changes the behavior of LayerTreeImpl::FindLayersUpToFirstOpaqueToHitTest (renamed from FindLayerUpToFirstScrollableOrOpaqueToHitTest): - For issue #1: LayerImpl::OpaqueToHitTest() also checks whether the layer is affected by any fast rounded corners; - For issue #2: FindLayerUpToFirstOpaqueToHitTest checks only OpaqueToHitTest() (without checking IsScrollerOrScrollbar()) because a hit test on a scrollable layer is reliable only if it's opaque to hit test. Bug: 40277896 Change-Id: I1acb16f2c6790760661e8239ea1599035f83ea51 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5466909 Commit-Queue: Xianzhu Wang <[email protected]> Reviewed-by: Steve Kobes <[email protected]> Cr-Commit-Position: refs/heads/main@{#1291538} -- wpt-commits: 9e7e1bd19fecd541ce4192e24039b746a88ce3df wpt-pr: 45797

…ug,dom-core Bug #1: AbstractRange::(Mark|Unmark)Descendants should always use the shadow tree of web-exposed shadow root, instead of using light DOM elements of the host. Bug #2: aRange could possibly create mCrossShadowBoundaryRange first (due to boundaries are in different tree), and later moves the boundaries to the same tree. When this happens, we should remove mCrossShadowBoundaryRange and use the default range to represent it. Differential Revision: https://phabricator.services.mozilla.com/D207608

We already cherry-picked this when we vendored fea41f540c. Upstream commit: https://webrtc.googlesource.com/src/+/93e9ac6285bceef08e4c44c221ec57e8f7995b2f [M124] Revert "pc: Include SCTP queued bytes in buffered_amount" This breaks file transfers with Chrome Remote Desktop, as reported in the internal bug tracker. This reverts commit fea41f540c72d15c4f499fead611a0c5e65db8ec. Bug: chromium:331346276 Change-Id: Ib41351a474bc40e7688d14dc445f53e68b5833ae Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344501 Commit-Queue: Victor Boivie <[email protected]> Reviewed-by: Florent Castelli <[email protected]> Reviewed-by: Tomas Gunnarsson <[email protected]> Cr-Commit-Position: refs/branch-heads/6367@{#2} Cr-Branched-From: 802552a8030d82ad07b72aa738f814f3a0030810-refs/heads/main@{#41921}

Feat/built-in extension

@page

…inting background., a=testonly Automatic update from web-platform-tests Get border/padding from fragment when painting background. Since @page border box layout objects aren't in the the layout tree, any code that wants to walk up the tree to find the containing block will be in for a surprise. This would happen if percentage-based @page padding was used [1]. Recomputing padding during painting when we have already done it during layout is rather pointless anyway. Read it out directly from the fragment. [1] #1 blink::LayoutBox::ContainingBlockLogicalWidthForContent() #2 blink::LayoutBoxModelObject::ComputedCSSPadding() #3 blink::LayoutBoxModelObject::PaddingTop() #4 blink::LayoutBoxModelObject::PaddingOutsets() #5 blink::BoxPainterBase::PaintFillLayer() #6 blink::BoxPainterBase::PaintFillLayers() #7 blink::BoxFragmentPainter::PaintBackground() Bug: 40286153 Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469 Commit-Queue: Morten Stenshorne <[email protected]> Reviewed-by: Xianzhu Wang <[email protected]> Reviewed-by: Ian Kilpatrick <[email protected]> Cr-Commit-Position: refs/heads/main@{#1300711} -- wpt-commits: 601b701a9d708b48a9cddae1ac15963d61be7964 wpt-pr: 46252

…-worker-reviewers,smaug,profiler-reviewers,aabh,asuth Use profiler markers to collect timing data. Markers of known name: AUTO_PROFILER_MARKER_TEXT("interesting thing #1", DOM, {}, ""_ns); AUTO_PROFILER_MARKER_TEXT("interesting thing #2", DOM, {}, ""_ns); can be inspected from the perftest: await startProfiler(); interestingThings(); let pdata = await stopProfiler(); let duration_ms = inspectProfile(pdata, [ "interesting thing #1", "interesting thing #2" ]); Differential Revision: https://phabricator.services.mozilla.com/D211368

We already cherry-picked this when we vendored 33cc83595a. Upstream commit: https://webrtc.googlesource.com/src/+/8505a9838ea91c66c96c173d30cd66f9dbcc7548 Revert "Ignore allocated bitrate during initial exponential BWE." This reverts commit 33cc83595ae7dd144c57c614fb62d286d9d7bf68. Reason for revert: Perf bots showed that this cl cause a change in metrics. It looks like it is for the better, but we want this to be behind a field trial. Original change's description: > Ignore allocated bitrate during initial exponential BWE. > > The reason why we want to do this is because audio can allocate a needed bitrate before video when starting a call, which may lead to a race between the first probe result and updating the allocated bitrate. > That is the, initial probe will try to probe up to the max configured bitrate. > > ProbeController::SetFirstProbeToMaxBitrate will allow the first probe to > continue up to the max configured bitrate, regardless of of the max > allocated bitrate. > > Bug: webrtc:14928 > Change-Id: I6e0ae90e21a78466527f3464951e6033dc846470 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346760 > Reviewed-by: Diep Bui <[email protected]> > Commit-Queue: Per Kjellander <[email protected]> > Reviewed-by: Erik Språng <[email protected]> > Reviewed-by: Per Kjellander <[email protected]> > Cr-Commit-Position: refs/heads/main@{#42049} (cherry picked from commit 501c4f37bfee47b26999ee291c5355ad64554df7) Bug: chromium:335337923,webrtc:14928 Change-Id: I56ba58560b6857b6069552c02df822691f7af64d Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/347622 Bot-Commit: [email protected] <[email protected]> Commit-Queue: Per Kjellander <[email protected]> Reviewed-by: Diep Bui <[email protected]> Owners-Override: Per Kjellander <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#42081} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/348722 Reviewed-by: Erik Språng <[email protected]> Cr-Commit-Position: refs/branch-heads/6422@{#2} Cr-Branched-From: b831eb816ef847d09d446ef4168e36b13af163f8-refs/heads/main@{#42072}

…-worker-reviewers,smaug,profiler-reviewers,aabh,asuth,perftest-reviewers,sparky Use profiler markers to collect timing data. Markers of known name: AUTO_PROFILER_MARKER_TEXT("interesting thing #1", DOM, {}, ""_ns); AUTO_PROFILER_MARKER_TEXT("interesting thing #2", DOM, {}, ""_ns); can be inspected from the perftest: await startProfiler(); interestingThings(); let pdata = await stopProfiler(); let duration_ms = inspectProfile(pdata, [ "interesting thing #1", "interesting thing #2" ]); Differential Revision: https://phabricator.services.mozilla.com/D211368

Upstream commit: https://webrtc.googlesource.com/src/+/876d0c9881eab8e7f8389812eb3738bdd374aa22 Fix use-of-uninitialized-value in NetEq tests. The new version of MSan (rolled by [1]) detects the following: ``` ==39908==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x5591400a52ef in GetPlayoutDelayMs ./../../modules/audio_coding/neteq/decision_logic.cc:466:35 #1 0x5591400a52ef in webrtc::DecisionLogic::ExpectedPacketAvailable(webrtc::NetEqController::NetEqStatus) ./../../modules/audio_coding/neteq/decision_logic.cc:311:36 #2 0x5591400a39e9 in webrtc::DecisionLogic::GetDecision(webrtc::NetEqController::NetEqStatus const&, bool*) ./../../modules/audio_coding/neteq/decision_logic.cc:0:0 #3 0x55913cf590c9 in webrtc::DecisionLogicTest_PreemptiveExpand_Test::TestBody() ./../../modules/audio_coding/neteq/decision_logic_unittest.cc:139:3 #4 0x55913ef28283 in HandleExceptionsInMethodIfSupported<testing::Test, void> ./../../third_party/googletest/src/googletest/src/gtest.cc:0:3 #5 0x55913ef28283 in testing::Test::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:2710:5 #6 0x55913ef2ab46 in testing::TestInfo::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:2856:11 #7 0x55913ef2da34 in testing::TestSuite::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:3034:30 #8 0x55913ef621e8 in testing::internal::UnitTestImpl::RunAllTests() ./../../third_party/googletest/src/googletest/src/gtest.cc:5964:44 #9 0x55913ef60f54 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> ./../../third_party/googletest/src/googletest/src/gtest.cc:0:0 #10 0x55913ef60f54 in testing::UnitTest::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:5543:10 #11 0x55913ee1a944 in RUN_ALL_TESTS ./../../third_party/googletest/src/googletest/include/gtest/gtest.h:2334:73 #12 0x55913ee1a944 in webrtc::(anonymous namespace)::TestMainImpl::Run(int, char**) ./../../test/test_main_lib.cc:203:21 #13 0x55913cbd36b8 in main ./../../test/test_main.cc:72:16 #14 0x7fdb18c73082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16 #15 0x55913cb3e1a9 in _start ??:0:0 ``` [1] - https://webrtc-review.googlesource.com/c/src/+/353620 Bug: b/344970813 Change-Id: I9b5d7791e68b4c494168ba9f007a3099ae21fed4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/353581 Auto-Submit: Mirko Bonadei <[email protected]> Reviewed-by: Jakob Ivarsson‎ <[email protected]> Commit-Queue: Jakob Ivarsson‎ <[email protected]> Cr-Commit-Position: refs/heads/main@{#42433}

Upstream commit: https://webrtc.googlesource.com/src/+/e7686023a186ac233ed1284da45cc166c0df4e1a [M128] PipeWire camera: Annotate functions with PipeWire calls to avoid CFI Similar to PipeWire implementation of desktop capture, we have to avoid CFI check for calls of dlopened PipeWire library. This avoid crashing PipeWire camera backend when "is_official_build=true" option is used as this turns on "is_cfi=true" enabling control flow integrity. iOS bots are broken due to xcode version mismatch. But the change is linux-only, so they are irrelevant. Disabling presubmit checks. (cherry picked from commit 9e755f0e19a9f3fdd5015283b5328fc65a7bfe1c) No-Try: true Bug: chromium:354776214 Change-Id: I7a9fc1c2d77c4ee0e8fe0586369b7246e0bb9180 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/358103 Commit-Queue: Jan Grulich <[email protected]> Reviewed-by: Ilya Nikolaevskiy <[email protected]> Reviewed-by: Alexander Cooper <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#42706} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359162 Commit-Queue: Ilya Nikolaevskiy <[email protected]> Reviewed-by: Jan Grulich <[email protected]> Cr-Commit-Position: refs/branch-heads/6613@{#2} Cr-Branched-From: 1ac162ee20a214bf97f6594a7effcbbc21f1effb-refs/heads/main@{#42664}

Update aboutHome.css

f834c8e

bug 939428

mshal added a commit to Nephyrin/mozilla-git that referenced this pull request Jan 14, 2014

Bug 880245 - Move EXTRA_JS_MODULES to moz.build (batch mozilla#2); r=…

fab4df7

…joey

hwine pushed a commit that referenced this pull request Jan 23, 2014

Bug 942164 - Fix merge error #2. a=bustage

e3598c4

ginayeh pushed a commit to ginayeh/gecko-dev that referenced this pull request Feb 5, 2014

Merge pull request mozilla#2 from ginayeh/tt-v2-bt

68cf03d

Add SourceEventType::BLUETOOTH

irvingreid pushed a commit to Nephyrin/mozilla-git that referenced this pull request Apr 29, 2014

Bug 966674: mozilla#2 Move exceptionStr() and stackTrace() from utils…

c53a02f

….js to Log.jsm; r=gps,rnewman

irvingreid pushed a commit to Nephyrin/mozilla-git that referenced this pull request May 8, 2014

Bug 1000695: mozilla#2 yield to event loop after receiving onInstallE…

633aa8b

…nded, rewrite to Task.jsm; r=unfocused

bsmedberg added a commit to Nephyrin/mozilla-git that referenced this pull request May 20, 2014

Bug 959356 try mozilla#2 - fix the spelling and type of the isWow64 m…

a24944a

…easurement, r=rnewman --HG-- extra : rebase_source : 1c07d8481b8152af39fea889504d4fdfef42da53

ttaubert pushed a commit to ttaubert/gecko-dev that referenced this pull request Aug 3, 2014

pkcs8 import mozilla#2 (wip)

fdaa73c

vagouzhou referenced this pull request in vagouzhou/gecko-dev Aug 10, 2014

#1refactoring device info logic , #2 fix some incorrect conflict merg…

35f13b9

…e on windows platform,mozilla#3 code format

hwine pushed a commit that referenced this pull request Aug 13, 2014

Bug 1050123 - Profiler Treeview: If arrow is the target of double cli…

62d7c81

…ck, children toggle three times (on click #1, click #2 and dblclick events). Ignore the dblclick on arrow. r=vp

edmorley closed this Aug 19, 2014

martinthomson added a commit to martinthomson/gecko-dev that referenced this pull request Sep 16, 2014

Merge pull request mozilla#2 from adamroach/multistream

0c66079

Changes to make group identifiers strings rather than integers

gavinsharp added a commit that referenced this pull request Nov 26, 2014

Bug 1102416 followup #2: fix tests, r+a=gavin

08786dc

hwine pushed a commit that referenced this pull request Dec 24, 2014

Bug 1111328: Add H264 SPS NAL decoder part #2 (VUI and HDR). r=kentuc…

a52d454

…kyfriedtakahe

hwine pushed a commit that referenced this pull request Jan 5, 2015

Bug 1111328 - Add H264 SPS NAL decoder part #2 (VUI and HDR). r=kentu…

53a3923

…ckyfriedtakahe, a=sledru

hwine pushed a commit that referenced this pull request Jan 5, 2015

Bug 1111328 - Add H264 SPS NAL decoder part #2 (VUI and HDR). r=kentu…

82c8bcf

…ckyfriedtakahe, a=sledru

rainemak pushed a commit to rainemak/gecko-dev-mirror that referenced this pull request Apr 7, 2015

Merge pull request mozilla#2 from special/use-system-nss-trust

515e617

Use the system NSS CA trust library

hwine pushed a commit that referenced this pull request Apr 10, 2015

Bug 1026350 followup #2: Use NS_IMETHOD instead of NS_IMETHODIMP for …

ff39c65

…function-decl that happens to provide inline impl, in FakeInputPortService.cpp. rs=froydnj

janjongboom added a commit to jan-os/gecko-dev that referenced this pull request Apr 20, 2015

Feedback from baku mozilla#2

59ee946

xeonchen added a commit to xeonchen/gecko-dev that referenced this pull request May 17, 2016

Merge pull request mozilla#2 from MDTsai/2.6_Bug_1197749

425aaa9

Bug 1197749 - Add RemoteControlService for remote control feature; a=jocheng

studioTeaTwo added a commit to studioTeaTwo/gecko-dev that referenced this pull request May 17, 2024

Merge pull request mozilla#2 from studioTeaTwo/feat/built-in-extension

082b98e

Feat/built-in extension

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update aboutHome.css #2

Update aboutHome.css #2

J0WI commented Jan 12, 2014

edmorley commented Aug 19, 2014

Update aboutHome.css #2

Update aboutHome.css #2

Conversation

J0WI commented Jan 12, 2014

edmorley commented Aug 19, 2014