Update aboutHome.css #2
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bug 939428
mshal
added a commit
to Nephyrin/mozilla-git
that referenced
this pull request
Jan 14, 2014
hwine
pushed a commit
that referenced
this pull request
Jan 23, 2014
ginayeh
pushed a commit
to ginayeh/gecko-dev
that referenced
this pull request
Feb 5, 2014
Add SourceEventType::BLUETOOTH
hwine
pushed a commit
that referenced
this pull request
Feb 11, 2014
======== https://hg.mozilla.org/integration/gaia-central/rev/3c7ae072e684 Author: Kyle Machulis <kyle@nonpolynomial.com> 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 <kyle@nonpolynomial.com> Desc: Bug 969950 - Cleaning up distribution sample ======== https://hg.mozilla.org/integration/gaia-central/rev/de97a5d865ef Author: Kyle Machulis <kyle@nonpolynomial.com> Desc: Bug 969650 - Subtree merge of yurenju/gaia-distribution-sample ======== https://hg.mozilla.org/integration/gaia-central/rev/eb9ae9a4503f Author: Yuren Ju <yurenju@gmail.com> 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 <jsmith@mozilla.com> 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 <yurenju@gmail.com> 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 <kevingrandon@yahoo.com> Desc: Add calendar.json ======== https://hg.mozilla.org/integration/gaia-central/rev/90aef8c4de58 Author: gasolin <gasolin@gmail.com> Desc: Create README.md ======== https://hg.mozilla.org/integration/gaia-central/rev/8f96ae99b519 Author: Yuren Ju <yurenju@gmail.com> 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 <gasolin@gmail.com> Desc: add runtime customize for bookmark setting ======== https://hg.mozilla.org/integration/gaia-central/rev/4e64191b5493 Author: Yuren Ju <yurenju@gmail.com> Desc: Initial commit
irvingreid
pushed a commit
to Nephyrin/mozilla-git
that referenced
this pull request
Apr 29, 2014
….js to Log.jsm; r=gps,rnewman
irvingreid
pushed a commit
to Nephyrin/mozilla-git
that referenced
this pull request
May 8, 2014
…nded, rewrite to Task.jsm; r=unfocused
hwine
pushed a commit
that referenced
this pull request
May 20, 2014
======== https://hg.mozilla.org/integration/gaia-central/rev/b55d2780462e Author: Etienne Segonzac <etienne@segonzac.info> 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 <etienne@segonzac.info> 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 <arnau@arnaumarch.com> 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 <pacorampas@gmail.com> Desc: Bug 1010129 - [Dialer] Replace outdated icons and add missing ones.
bsmedberg
added a commit
to Nephyrin/mozilla-git
that referenced
this pull request
May 20, 2014
…easurement, r=rnewman --HG-- extra : rebase_source : 1c07d8481b8152af39fea889504d4fdfef42da53
vagouzhou
referenced
this pull request
in vagouzhou/gecko-dev
Aug 10, 2014
…e on windows platform,mozilla#3 code format
hwine
pushed a commit
that referenced
this pull request
Aug 13, 2014
…ck, children toggle three times (on click #1, click #2 and dblclick events). Ignore the dblclick on arrow. r=vp
|
(Mass-PR-close) |
martinthomson
added a commit
to martinthomson/gecko-dev
that referenced
this pull request
Sep 16, 2014
Changes to make group identifiers strings rather than integers
gavinsharp
added a commit
that referenced
this pull request
Nov 26, 2014
hwine
pushed a commit
that referenced
this pull request
Dec 24, 2014
hwine
pushed a commit
that referenced
this pull request
Jan 12, 2015
… 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]
hwine
pushed a commit
that referenced
this pull request
Apr 10, 2015
…function-decl that happens to provide inline impl, in FakeInputPortService.cpp. rs=froydnj
rocallahan
added a commit
that referenced
this pull request
Jul 7, 2015
…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
hwine
pushed a commit
that referenced
this pull request
Sep 9, 2015
======== https://hg.mozilla.org/integration/gaia-central/rev/20db0a074a97 Author: Johan Lorenzo <jlorenzo@mozilla.com> 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 <jlorenzo@mozilla.com> Desc: Bug 1196717 - Dogfood test - Delete thread in SMS ======== https://hg.mozilla.org/integration/gaia-central/rev/e9b47d1d18c0 Author: Etienne Segonzac <etienne@segonzac.info> 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 <etienne@segonzac.info> 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 <jlorenzo@mozilla.com> 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 <jlorenzo@mozilla.com> Desc: Bug 1184511 - [Aries] test_settings_device_info fails because only 1 IMEI is displayed
ehsan
pushed a commit
to ehsan/gecko-dev
that referenced
this pull request
Sep 11, 2015
======== https://hg.mozilla.org/integration/gaia-central/rev/20db0a074a97 Author: Johan Lorenzo <jlorenzo@mozilla.com> 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 <jlorenzo@mozilla.com> Desc: Bug 1196717 - Dogfood test - Delete thread in SMS ======== https://hg.mozilla.org/integration/gaia-central/rev/e9b47d1d18c0 Author: Etienne Segonzac <etienne@segonzac.info> 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 <etienne@segonzac.info> 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 <jlorenzo@mozilla.com> 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 <jlorenzo@mozilla.com> Desc: Bug 1184511 - [Aries] test_settings_device_info fails because only 1 IMEI is displayed
janjongboom
added a commit
to jan-os/gecko-dev
that referenced
this pull request
Oct 19, 2015
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 92272760580ee1b81a1b5e56417e079fdba17ffb. 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
hwine
pushed a commit
that referenced
this pull request
Dec 17, 2015
======== https://hg.mozilla.org/integration/gaia-central/rev/670bb87fcd72 Author: Johan Lorenzo <jlorenzo@mozilla.com> 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 <jlorenzo@mozilla.com> Desc: Bug 1230099 - Delete tests already ported to Gij - round #2
xeonchen
added a commit
to xeonchen/gecko-dev
that referenced
this pull request
May 17, 2016
Bug 1197749 - Add RemoteControlService for remote control feature; a=jocheng
moz-v2v-gh
pushed a commit
that referenced
this pull request
Jul 11, 2016
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
moz-v2v-gh
pushed a commit
that referenced
this pull request
Jul 7, 2023
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 <mbonadei@webrtc.org> Commit-Queue: Markus Handell <handellm@webrtc.org> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/main@{#39400}
moz-v2v-gh
pushed a commit
that referenced
this pull request
Aug 2, 2023
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 <hta@webrtc.org> Commit-Queue: Philipp Hancke <phancke@microsoft.com> Reviewed-by: Henrik Boström <hbos@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40029} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305420 Commit-Queue: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/5735@{#2} Cr-Branched-From: df7df199abd619e75b9f1d9a7e12fc3f3f748775-refs/heads/main@{#39949}
moz-v2v-gh
pushed a commit
that referenced
this pull request
Aug 29, 2023
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 <hta@webrtc.org> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40197} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308000 Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/5790@{#2} Cr-Branched-From: 2eacbbc03a4a41ea658661225eb1c8fc07884c33-refs/heads/main@{#40122}
moz-v2v-gh
pushed a commit
that referenced
this pull request
Sep 28, 2023
…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 <blee@igalia.com>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1198137}
--
wpt-commits: 2f5741f704e062180e3424c1126ba5b30cf6dd07
wpt-pr: 42012
moz-v2v-gh
pushed a commit
that referenced
this pull request
Oct 2, 2023
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 <ilnik@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Per Kjellander <perkj@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40335} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310500 Reviewed-by: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/branch-heads/5845@{#2} Cr-Branched-From: f80cf814353d11a9f22bef5ce5e8868f2c72f0d0-refs/heads/main@{#40319}
moz-v2v-gh
pushed a commit
that referenced
this pull request
Oct 23, 2023
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 <ssilkin@webrtc.org> Commit-Queue: Harald Alvestrand <hta@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40673} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/319100 Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org> Cr-Commit-Position: refs/branch-heads/5938@{#2} Cr-Branched-From: 82e5f91a2bdf955aa870142008fbdc9ac12f6acd-refs/heads/main@{#40524}
moz-v2v-gh
pushed a commit
that referenced
this pull request
Nov 16, 2023
…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
moz-v2v-gh
pushed a commit
that referenced
this pull request
Nov 21, 2023
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 <hta@webrtc.org> Reviewed-by: Henrik Boström <hbos@webrtc.org> Commit-Queue: Philipp Hancke <phancke@microsoft.com> 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}
moz-v2v-gh
pushed a commit
that referenced
this pull request
Dec 20, 2023
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 <hta@webrtc.org> Commit-Queue: Florent Castelli <orphis@webrtc.org> 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 <guidou@webrtc.org> Cr-Commit-Position: refs/branch-heads/6045@{#2} Cr-Branched-From: bce7ce7ba054ac0e79fed49b84ef52fb24c31778-refs/heads/main@{#40854}
moz-v2v-gh
pushed a commit
that referenced
this pull request
Jan 23, 2024
…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
mstriemer
pushed a commit
to mstriemer/gecko-dev
that referenced
this pull request
Feb 13, 2024
…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
moz-v2v-gh
pushed a commit
that referenced
this pull request
Feb 22, 2024
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 <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Sam Zackrisson <saza@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#41374} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331960 Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/6167@{#2} Cr-Branched-From: ece5cb83715dea85617114b6d4e981fdee2623ba-refs/heads/main@{#41315}
TGiles
added a commit
to TGiles/gecko-dev
that referenced
this pull request
Mar 5, 2024
…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
moz-v2v-gh
pushed a commit
that referenced
this pull request
Apr 15, 2024
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 <hta@webrtc.org> Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Philipp Hancke <phancke@microsoft.com> 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}
moz-v2v-gh
pushed a commit
that referenced
this pull request
Apr 29, 2024
…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 <wangxianzhu@chromium.org> Reviewed-by: Steve Kobes <skobes@chromium.org> Cr-Commit-Position: refs/heads/main@{#1291538} -- wpt-commits: 9e7e1bd19fecd541ce4192e24039b746a88ce3df wpt-pr: 45797
moz-v2v-gh
pushed a commit
that referenced
this pull request
May 7, 2024
…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
moz-v2v-gh
pushed a commit
that referenced
this pull request
May 14, 2024
…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
moz-v2v-gh
pushed a commit
that referenced
this pull request
May 15, 2024
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 <boivie@webrtc.org> Reviewed-by: Florent Castelli <orphis@webrtc.org> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Cr-Commit-Position: refs/branch-heads/6367@{#2} Cr-Branched-From: 802552a8030d82ad07b72aa738f814f3a0030810-refs/heads/main@{#41921}
moz-v2v-gh
pushed a commit
that referenced
this pull request
May 23, 2024
…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 <mstensho@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1300711} -- wpt-commits: 601b701a9d708b48a9cddae1ac15963d61be7964 wpt-pr: 46252
moz-v2v-gh
pushed a commit
that referenced
this pull request
Jun 11, 2024
…-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
moz-v2v-gh
pushed a commit
that referenced
this pull request
Jun 12, 2024
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 <diepbp@webrtc.org> > Commit-Queue: Per Kjellander <perkj@webrtc.org> > Reviewed-by: Erik Språng <sprang@webrtc.org> > Reviewed-by: Per Kjellander <perkj@webrtc.org> > 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: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Per Kjellander <perkj@webrtc.org> Reviewed-by: Diep Bui <diepbp@webrtc.org> Owners-Override: Per Kjellander <perkj@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#42081} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/348722 Reviewed-by: Erik Språng <sprang@webrtc.org> Cr-Commit-Position: refs/branch-heads/6422@{#2} Cr-Branched-From: b831eb816ef847d09d446ef4168e36b13af163f8-refs/heads/main@{#42072}
moz-v2v-gh
pushed a commit
that referenced
this pull request
Jul 27, 2024
…-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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
bug 939428