Skip to content
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

Conversation

TGiles
Copy link

@TGiles TGiles commented Jan 19, 2024

No description provided.

Jules Simplicio and others added 3 commits January 19, 2024 10:26
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
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
Copy link

@hannajones hannajones left a 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 TGiles merged commit 08851e3 into FirefoxUX:json-design-tokens Jan 19, 2024
@TGiles TGiles deleted the 1850611-json-design-tokens branch January 19, 2024 20:51
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants