| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Sorry for the delay, just one minor comment.
// Returns true if this element is a native password field or has been
// identified as a custom password field via CSS or JS heuristics.
virtual bool IsNativeOrHeuristicPassword() const;Can we avoid adding this virtual API here? This is being used to detect if this is a native password from ShouldTrackPassword which is already virtual. So we can fold it into ShouldTrackPassword() itself?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// Returns true if this element is a native password field or has been
// identified as a custom password field via CSS or JS heuristics.
virtual bool IsNativeOrHeuristicPassword() const;Can we avoid adding this virtual API here? This is being used to detect if this is a native password from ShouldTrackPassword which is already virtual. So we can fold it into ShouldTrackPassword() itself?
I added this function so that it's clear to answer 1. if this is a password (IsNativeOrHeuristicPassword) 2. should we track this element if it's a password (ShouldTrackPassword). We can definitely fold it into ShouldTrackPassword(), but that would complicate ShouldTrackPassword() and duplicate some logic (e.g. HtmlInputElement would need to check if the value is empty or not, which is currently handled by TextControlElement). I don't feel strongly, but please let me know if you prefer to have one fewer virtual function. Thanks.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// Returns true if this element is a native password field or has been
// identified as a custom password field via CSS or JS heuristics.
virtual bool IsNativeOrHeuristicPassword() const;Nan LinCan we avoid adding this virtual API here? This is being used to detect if this is a native password from ShouldTrackPassword which is already virtual. So we can fold it into ShouldTrackPassword() itself?
I added this function so that it's clear to answer 1. if this is a password (IsNativeOrHeuristicPassword) 2. should we track this element if it's a password (ShouldTrackPassword). We can definitely fold it into ShouldTrackPassword(), but that would complicate ShouldTrackPassword() and duplicate some logic (e.g. HtmlInputElement would need to check if the value is empty or not, which is currently handled by TextControlElement). I don't feel strongly, but please let me know if you prefer to have one fewer virtual function. Thanks.
Ack. Keeping them separate also seems good.
Nan LinOne high level question for this CL, and something I missed for the iframe case,
sorry i thought i sent it yesterday. :)why do we dynamically add/remove element tracking when an element is inserted or detached from the DOM?
It seems we have state changes which initiate tracking (if it's an iframe element, if it's an input element with type=password, if it's an input element which has CSS applied that heuristically makes it a password). And once that's initiated, the element continues to be tracked. If the element has been detached, it will no longer be in the layout or paint tree so it won't show up in the data provided by the compositor. But there's no reason to remove the tracking, it seems like we're creating unnecessary complexity.
So how about we create one helper to add the element to the tracking list. And any place where the state that initiates tracking changes, calls that helper.
Nan LinThanks Khushal, that makes a lot of sense. I agreed that although detached elements don't need to be tracked, it adds more complexity. I'll simplify the implementation by removing the dynamic add/remove logic from `InsertedInto` and `RemovedFrom`. Since the compositor ignores elements without a layout object, we only need to ensure the tracking state is correctly set based on whether the element is a password field (via type or heuristics).
Element::UpdatePasswordTracking() is the helper function that is called when the state changes for password. I'll remove the `isConnected()` check there as well.
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
12 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
Track password elements using the TrackedElement framework
This CL leverages the existing TrackedElement infrastructure to track
the coordinates of password elements. This is a prerequisite for
screenshot redaction via compositor, ensuring that sensitive fields can
be accurately masked in sync with the captured viewport bitmap.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |