FilterOperationResolver uses it for filter parsing on Worker's OffscreenCanvas.

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/resolver/FilterOperationResolver.cpp?type=cs&q=CreateOffscreenFilterOperations&sq=package:chromium&l=208

There may be other cases, since it's not uncommon that specs reference CSS parsing.

As @esprehn pointed out:
I think the current code is currently okay because:
- initialStyle() returns a const reference
- CSSToLengthConversionData takes a raw ptr to a ComputedStyle and doesn't store it in a RefPtr.

But from a system design perspective these classes can only be used from main, for example we might lazy allocate the nested fields inside it, or something inside CSSToLengthConversionData could call a function that refs the style.

this should be currently safe unless CSSToLengthConversionData ever decides to start changing something global. At this point, I'd say that we probably need to fork CSSToLengthConversionData (and CHECK the proper threads) and keep a thread-safe version of it. Design-wise, I don't know how to make this explicit, except for having what we currently do: have tests on separate threads and hope that when the function becomes unsafe there will be a new CHECK that will fail.

(This bug has been moved from  http://crbug.com/703908 , since that issue is closed)