Bug 1557689 Comment 5 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Gabriel [:gl] (ΦωΦ) from comment #4)
> Unfortunately, I don't have any solutions to your problem. I will add a couple of notes based on my observation which might help feed this discussion. I haven't gone too deep in testing this, so, my observations might just be invalid.
> 

Anything is welcome at this point.

> We don't currently use or respond to any `reflows` event in the Rules view. The closest thing we have is [InspectorStyleChangeTracker](https://searchfox.org/mozilla-central/source/devtools/client/inspector/shared/style-change-tracker.js#21), which only listens to `resize` events from the walker. 
> 

Yes, I left them in just to give a complete picture.

> I would like us to explore options where we ensure that by step 11 where we call `element-style::updateDeclarations()` that the style change has already been applied to the content. That would remove additional listeners or another roundtrip to update. 
> 

Maybe that is possible... I will look into it.

> Another thought that comes to my mind is that `isUsed` is static since it's in the form. I am not quite sure this is a good idea since you would have to explicitly overwrite it in order for it to be updated. I have seen this with the walker and how it queues node mutations to update the node's form() https://searchfox.org/mozilla-central/source/devtools/shared/fronts/node.js#189.  So, is it possible that we are just always returning the same value for `isUsed` because it is in the form?

`isUsed` being static is the root of the problem but we are having trouble finding anywhere else that we could put this code. We don't necessarily always return the same value but it may not be up-to-date when we update the UI.
(In reply to Gabriel [:gl] (ΦωΦ) from comment #4)
> Unfortunately, I don't have any solutions to your problem. I will add a couple of notes based on my observation which might help feed this discussion. I haven't gone too deep in testing this, so, my observations might just be invalid.
> 

Anything is welcome at this point.

> We don't currently use or respond to any `reflows` event in the Rules view. The closest thing we have is [InspectorStyleChangeTracker](https://searchfox.org/mozilla-central/source/devtools/client/inspector/shared/style-change-tracker.js#21), which only listens to `resize` events from the walker. 
> 

Yes, I left them in just to give a complete picture.

> I would like us to explore options where we ensure that by step 11 where we call `element-style::updateDeclarations()` that the style change has already been applied to the content. That would remove additional listeners or another roundtrip to update. 
> 

The irony is that before step 11 the styles have not been applied to content yet... our calculations are correct but they are based on a DOM that is lagging behind.

Maybe we could use `requestIdleCallback` before updating the UI.

> Another thought that comes to my mind is that `isUsed` is static since it's in the form. I am not quite sure this is a good idea since you would have to explicitly overwrite it in order for it to be updated. I have seen this with the walker and how it queues node mutations to update the node's form() https://searchfox.org/mozilla-central/source/devtools/shared/fronts/node.js#189.  So, is it possible that we are just always returning the same value for `isUsed` because it is in the form?

`isUsed` being static is the root of the problem but we are having trouble finding anywhere else that we could put this code. We don't necessarily always return the same value but it may not be up-to-date when we update the UI.

Back to Bug 1557689 Comment 5