Cache OPAQUE1 state (no state change event)
Categories
(Core :: Disability Access APIs, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox100 | --- | fixed |
People
(Reporter: eeejay, Assigned: morgan)
References
(Blocks 1 open bug)
Details
(Whiteboard: [ctw-m1])
Attachments
(1 file)
|
(deleted),
text/x-phabricator-request
|
Details |
I think it is mostly Android that cares about this.
This is hard to do because this state is style-derived.
|
Reporter | |
Comment 1•3 years ago
|
||
Changing severity to S3 because this is ongoing cache the world work that does not affect current users.
|
|
Reporter | |
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
Assignee | |
Comment 2•3 years ago
|
||
:Jamie is this still an M1 deliverable?
|
|
Assignee | |
Updated•3 years ago
|
|
|
Reporter | |
Comment 3•3 years ago
|
||
Pasting from a convo what I think we should do here. I don't think we should fire state change events for OPAQUE1 changes. Instead quietly caching opacity is a better idea.
i think we need opacity cached in the remote with a common method like double Accessible::Opacity(), that method could be used in the remote case to calculate OPAQUE1 state. i got more androidy things to do so if either of you wants to dig in, go ahead. not worries if not. i can loop back to this.
|
|
||
Comment 4•3 years ago
|
||
Yes, it's m1 because it's needed by Android.
We should be able to use the new style change stuff to manage this. We can include it in CacheDomain::Style.
|
|
Assignee | |
Comment 5•3 years ago
|
||
|
||
Updated•3 years ago
|
|
||
Comment 7•3 years ago
|
||
| bugherder | ||
Description
•