forked from mozilla/gecko-dev
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add base feature branch for the style dictionary experiment work #1
Merged
TGiles
merged 3 commits into
FirefoxUX:json-design-tokens
from
TGiles:1850611-json-design-tokens
Jan 19, 2024
Merged
Add base feature branch for the style dictionary experiment work #1
TGiles
merged 3 commits into
FirefoxUX:json-design-tokens
from
TGiles:1850611-json-design-tokens
Jan 19, 2024
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
Introducing a JSON file that holds our design tokens source of truth in an agnostic format. The plan is to generate desktop and mobile tokens from this file. We will be exploring a build process as a next step, potentially relying on Style Dictionary. This is the format we're playing with for now, but not set in stone. Differential Revision: https://phabricator.services.mozilla.com/D189153 Depends on D194165
…tokens Differential Revision: https://phabricator.services.mozilla.com/D198707
Note: We still need to determine how to get "prefers-contrast" and "light-dark" transforms to work. We should also determine how to get aliases to work as expected so that tokens that reference other tokens use CSS variables instead of raw values. Differential Revision: https://phabricator.services.mozilla.com/D198702
hannajones
approved these changes
Jan 19, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's get this party started
TGiles
pushed a commit
that referenced
this pull request
Jan 25, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/b0cc68e61205fd11a7256a6e85307ec17ad95790 Reduces rate at which TryGetNextFrame returns NULL for WGC This CL is a follow-up of work done in https://webrtc-review.googlesource.com/c/src/+/323882 where the goal was to reduce the amount of FrameDropped error logs in WebRTC.DesktopCapture.Win.WgcCaptureSessionGetFrameResult. The previous work avoids FrameDropped logs for a minimized window being captured with WGC but we still se a large amount of these error (or rather warning) logs. See [1] which comes from Canary. This CL does two different things to improve the situation: 1) It adds kFramePoolEmpty to the existing GetFrameResult::kFrameDropped enum to point out that the warning comes from the frame pool not being able to return a valid new frame. It also makes it more clear that it does not cause an outer/final error as WgcCapturerResult::kFrameDropped. We still keep the inner GetFrameResult::kFrameDropped but it is only produced when the frame pool returns NULL and our external queue is empty. Hence, a real frame-drop error. Note that, it is still easy to provoke kFramePoolEmpty simply by asking for a high resolution at a high rate. The example in [2] comes from a 4K screen @30fps. Hence, we have not fixed anything yet. 2) It also increases the size of the internal frame pool from 1 to 2. This does lead to an almost zero rate of kFramePoolEmpt warnings at the expense of a slightly reduced max capture rate. BUT, with 1 as size, we can "see" a higher max capture rate but it is not a true rate since it comes with a high rate of kFramePoolEmpty errors. Hence, we "emulate" a high capture rate by simply feeding copies of the last frame that we had stored in the external queue. Using 2 leads to a more "true" rate of what we actually can capture in terms of *new* frames and also a substantially lower rate of kFramePoolEmpty. In addition, with 1 as size, if we ask at a too high rate and provide a copy of the last frame, our CPU adaptation will not reduce its rate since we think that things are OK when it is actually not. Also, the samples in [3] and [4] both use 2 as numberOfBuffers as well. Let me also mention that with this small change, I a have not been able to provoke any kFramePoolEmpty error messages. Finally, geDisplayMedia can be called called with constraints where min and max framerate is defined. The mechanism which maintains the min rate is implemented via the RequestRefreshFrame API and it can be sent to the source (DesktopCaptureDevice) back to back with a previous timer interrupt for a capture request. Without this change, these RRFs were also a source of a large amount of kFramePoolEmpty error logs. With 2 buffers instead; this is no longer the case. [1] https://screenshot.googleplex.com/7sfv6HdGXLwyxdj [2] https://paste.googleplex.com/4795680001359872 [3] https://github.com/robmikh/Win32CaptureSample/blob/master/Win32CaptureSample/SimpleCapture.cpp [4] https://learn.microsoft.com/en-us/windows/uwp/audio-video-camera/screen-capture#add-the-screen-capture-capability (cherry picked from commit 4be5927dc788b814dff2a6ca46175254dce59232) Bug: chromium:1314868 Change-Id: I73b823b31a993fd2cd6e007b212826dfe1a80012 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325521 Commit-Queue: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Alexander Cooper <alcooper@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#41079} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326960 Commit-Queue: Henrik Andreassson <henrika@webrtc.org> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: Stefan Holmer <stefan@webrtc.org> Cr-Commit-Position: refs/branch-heads/6099@{#1} Cr-Branched-From: 507f1cc3270d0577f79882acbd78e63e66008f3d-refs/heads/main@{#41042}
TGiles
pushed a commit
that referenced
this pull request
Jan 25, 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 mozilla#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 mozilla#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 mozilla#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 mozilla#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 mozilla#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 mozilla#21 0x00005cc60badb535 in mozilla::net::ChannelEventQueue::FlushQueue() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/netwerk/ipc/ChannelEventQueue.cpp:90 mozilla#22 0x00005cc60b976fda in mozilla::net::ChannelEventQueue::MaybeFlushQueue() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/net/ChannelEventQueue.h:350 mozilla#23 0x00005cc60baec442 in mozilla::net::ChannelEventQueue::CompleteResume() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/net/ChannelEventQueue.h:329 mozilla#24 mozilla::net::ChannelEventQueue::ResumeInternal()::CompleteResumeRunnable::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/ipc/ChannelEventQueue.cpp:148 mozilla#25 0x00005cc60b53d4f1 in mozilla::SchedulerGroup::Runnable::Run() (this=0x685b0200) at /home/emilio/src/moz/gecko/xpcom/threads/SchedulerGroup.cpp:282 mozilla#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 mozilla#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
TGiles
added a commit
that referenced
this pull request
Feb 15, 2024
* Bug 1850611 - Create a JSON file source of truth for our design tokens Introducing a JSON file that holds our design tokens source of truth in an agnostic format. The plan is to generate desktop and mobile tokens from this file. We will be exploring a build process as a next step, potentially relying on Style Dictionary. This is the format we're playing with for now, but not set in stone. Differential Revision: https://phabricator.services.mozilla.com/D189153 Depends on D194165 * working example of style dictionary with very small amount of design tokens Differential Revision: https://phabricator.services.mozilla.com/D198707 * Reduced JSON design tokens to get Style Dictionary to build Note: We still need to determine how to get "prefers-contrast" and "light-dark" transforms to work. We should also determine how to get aliases to work as expected so that tokens that reference other tokens use CSS variables instead of raw values. Differential Revision: https://phabricator.services.mozilla.com/D198702 --------- Co-authored-by: Jules Simplicio <jsimplicio@mozilla.com>
TGiles
pushed a commit
that referenced
this pull request
Feb 26, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/004a624023ce8b01c0f9d8a62fc13390d604ce34 [121] Ensure cloning and then sending audio encoded frames propagates CSRCs (cherry picked from commit 5f3ac435518cd5c05a74b58419fe6cfc504fc7da) Bug: chromium:1508337 Change-Id: I9f28fc0958d28bc97f9378a46fbec3e45148736f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330260 Reviewed-by: Guido Urdaneta <guidou@webrtc.org> Commit-Queue: Tony Herre <herre@google.com> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#41337} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330564 Commit-Queue: Guido Urdaneta <guidou@webrtc.org> Cr-Commit-Position: refs/branch-heads/6167@{#1} Cr-Branched-From: ece5cb83715dea85617114b6d4e981fdee2623ba-refs/heads/main@{#41315}
TGiles
added a commit
that referenced
this pull request
Mar 5, 2024
* Bug 1850611 - Create a JSON file source of truth for our design tokens Introducing a JSON file that holds our design tokens source of truth in an agnostic format. The plan is to generate desktop and mobile tokens from this file. We will be exploring a build process as a next step, potentially relying on Style Dictionary. This is the format we're playing with for now, but not set in stone. Differential Revision: https://phabricator.services.mozilla.com/D189153 Depends on D194165 * working example of style dictionary with very small amount of design tokens Differential Revision: https://phabricator.services.mozilla.com/D198707 * Reduced JSON design tokens to get Style Dictionary to build Note: We still need to determine how to get "prefers-contrast" and "light-dark" transforms to work. We should also determine how to get aliases to work as expected so that tokens that reference other tokens use CSS variables instead of raw values. Differential Revision: https://phabricator.services.mozilla.com/D198702 --------- Co-authored-by: Jules Simplicio <jsimplicio@mozilla.com>
TGiles
added a commit
that referenced
this pull request
Mar 8, 2024
* Bug 1850611 - Create a JSON file source of truth for our design tokens Introducing a JSON file that holds our design tokens source of truth in an agnostic format. The plan is to generate desktop and mobile tokens from this file. We will be exploring a build process as a next step, potentially relying on Style Dictionary. This is the format we're playing with for now, but not set in stone. Differential Revision: https://phabricator.services.mozilla.com/D189153 Depends on D194165 * working example of style dictionary with very small amount of design tokens Differential Revision: https://phabricator.services.mozilla.com/D198707 * Reduced JSON design tokens to get Style Dictionary to build Note: We still need to determine how to get "prefers-contrast" and "light-dark" transforms to work. We should also determine how to get aliases to work as expected so that tokens that reference other tokens use CSS variables instead of raw values. Differential Revision: https://phabricator.services.mozilla.com/D198702 --------- Co-authored-by: Jules Simplicio <jsimplicio@mozilla.com>
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.
No description provided.