Bugzilla

(In reply to Thorin [:thorin] from comment #18)
> daniel ... a border PoC has been in TZP since jesus, just saying .. https://arkenfox.github.io/TZP/tzp.html#screen
> [...]
> - edit: made https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42048 no longer confidential

Thanks; that does seem like it's the same thing I'm talking about, yeah.

My hypothetical CSS-only container-query-style approach in comment 17 is probably not in TZP (since container queries are relatively recent).  Writing a PoC for that would be a small amount of work, but it's quite possible to do so in theory.

> Note, this is not a zero sum game - making scripts use the dom and elements as a method is a bonus. Maybe we'll close those loops in the future.

Right. Just wanted to be sure we were aware that the existing hurdle's bypassability is considered when evaluating the benefits against the costs, with e.g. the site-breakage referenced in comment 1 being an example of a cost.  (I know the cost-vs-benefit judgement is fuzzy as with all rFP-style interventions; and maybe the benefit is indeed worth it in this case; I'm not sure.)

> Also your PoC ~~returns `2` for me with RFP on, but on TZP, I still get my real value of `1`. Not sure if your PoC works,

Yeah, sorry -- I should've said, my PoC only tries to output an inferred value if your true devicePixelRatio is greater than 1.  That was just laziness on my part in writing the PoC.  If your true devicePixelRatio is 1 and you want to try the attached PoC, you can try applying full-page-zoom which should make the logic activate and start printing out an inferred devicePixelRatio.

> doesn't output the inferred value when viewed as an attachment :-(

FWIW I'm not seeing any difference in behavior when viewing it as an attachment vs. not; but I don't want to sidetrack on PoC diagnosis too much here so I won't worry about this. :)

(In reply to Thorin [:thorin] from comment #18)
> daniel ... a border PoC has been in TZP since jesus, just saying .. https://arkenfox.github.io/TZP/tzp.html#screen
> [...]
> - edit: made https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42048 no longer confidential

Thanks; that does seem like it's the same thing I'm talking about, yeah.

My hypothetical CSS-only container-query-style approach in comment 17 is probably not in TZP (since container queries are relatively recent).  Writing a PoC for that would be a small amount of work, but it's quite possible to do so in theory.

> Note, this is not a zero sum game - making scripts use the dom and elements as a method is a bonus. Maybe we'll close those loops in the future.

Right. Just wanted to be sure that the existing hurdle's bypassability is considered, when evaluating the benefits against the costs, with e.g. the site-breakage referenced in comment 1 being an example of a cost.  (I know the cost-vs-benefit judgement is fuzzy as with all rFP-style interventions; and maybe the benefit is indeed worth it in this case; I'm not sure.)

> Also your PoC ~~returns `2` for me with RFP on, but on TZP, I still get my real value of `1`. Not sure if your PoC works,

Yeah, sorry -- I should've said, my PoC only tries to output an inferred value if your true devicePixelRatio is greater than 1.  That was just laziness on my part in writing the PoC.  If your true devicePixelRatio is 1 and you want to try the attached PoC, you can try applying full-page-zoom which should make the logic activate and start printing out an inferred devicePixelRatio.

> doesn't output the inferred value when viewed as an attachment :-(

FWIW I'm not seeing any difference in behavior when viewing it as an attachment vs. not; but I don't want to sidetrack on PoC diagnosis too much here so I won't worry about this. :)

(In reply to Thorin [:thorin] from comment #18)
> daniel ... a border PoC has been in TZP since jesus, just saying .. https://arkenfox.github.io/TZP/tzp.html#screen
> [...]
> - edit: made https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42048 no longer confidential

Thanks; that does seem like it's the same thing I'm talking about, yeah.

My hypothetical CSS-only container-query-style approach in comment 17 is probably not in TZP (since container queries are relatively recent).  Writing a PoC for that would be a small amount of work, but it's quite possible to do so in theory.

> Note, this is not a zero sum game - making scripts use the dom and elements as a method is a bonus. Maybe we'll close those loops in the future.

Right. Just wanted to be sure that the existing hurdle's bypassability is considered, when evaluating the benefits against the costs, with e.g. the site-breakage referenced in comment 1 being an example of a cost.  (I know the cost-vs-benefit judgement is fuzzy as with all rFP-style interventions; and maybe the benefit is indeed worth it in this case; I'm not sure.)

> Also your PoC ~~returns `2` for me with RFP on, but on TZP, I still get my real value of `1`. Not sure if your PoC works,

Yeah, sorry -- I should've said, my PoC only tries to output an inferred value if your true devicePixelRatio is greater than 1.  That was just laziness on my part in writing the PoC.  If your true devicePixelRatio is 1 and you want to try the attached PoC, you can try applying full-page-zoom which should make the logic activate and start printing out an inferred devicePixelRatio (which would then be your full-page-zoom zoom-factor; full-page-zoom is essentially the same sort of scaling as HiDPI scaling, under the hood).

> doesn't output the inferred value when viewed as an attachment :-(

FWIW I'm not seeing any difference in behavior when viewing it as an attachment vs. not; but I don't want to sidetrack on PoC diagnosis too much here so I won't worry about this. :)