htmlelement keys is not stable between TZP vs CREEPY #267
Comments
Thorin-Oakenpants
changed the title
|
I thought maybe something in TZP mountain of html/css/js was causing it, but nope - here's a standalone test (using my code which came from you) <html><body>
<br>HASH<br><div id="hash"></div><br>DATA<br><div id="data"></div>
<script>
'use strict';
function mini(str) {
// https://stackoverflow.com/a/22429679
const json = `${JSON.stringify(str)}`
let i, len, hash = 0x811c9dc5
for (i = 0, len = json.length; i < len; i++) {
hash = Math.imul(31, hash) + json.charCodeAt(i) | 0
}
return ('0000000' + (hash >>> 0).toString(16)).slice(-8)
}
try {
const id = "html-element-version"
const element = document.createElement("div")
element.setAttribute("id", id)
document.body.appendChild(element)
const htmlElement = document.getElementById(id)
const keys = []
for (const key in htmlElement) {keys.push(key)}
try {document.getElementById(id).remove()} catch(e) {}
let hash = mini(keys) // 18527130
document.getElementById("hash").innerHTML = hash +" [" + keys.length +"]"
document.getElementById("data").innerHTML = "['"+ keys.join("', '") +"']"
} catch (e) {
document.getElementById("hash").innerHTML = e+""
}
</script></body></html>here's the result
|
|
the only place if I compare just your hash is different - so I can only surmise you are not testing a |
|
I use HTML. It's a little faster if we grab the live element. const keys = []
for (const key in document.documentElement) keys.push(key) |
|
ahhh so that explains it anyway, live test to be added ...
The interesting things about these is that almost all of them have a massive chunk of values the same and in the same order. In gecko this seems to be everything after
so if you look at the image above which gecko, they are all the same from c so we could actually enumerate every element and reduce the noise and record like such data_common {
b1cd1557: [array of 312 items],
f5bf2f92: [array of 311 items], // as an example, the has is actually something else
},
data {
hr: ["align","color","noShade","size","width", "b1cd1557"] // <- i.e 5 items + data_common.b1cd1557
option: ["disabled","form","label","defaultSelected","selected","value","text","index","b1cd1557"]
meter: ["value"."min"."max"."low"."high"."optimum"."labels", "b1cd1557"],
select: [ "item","namedItem","add","remove", .... "f5bf2f92"] // <-- select is slightly different has data_common.f5bf2f92
}This then comprehensively covers everything Once I finish this PoC, I will check stability over time, because the common shit we only need once, but the others may not be worth while collecting if they're super stable and haven't changed e.g. since FF115 (TZP is only concerned with ESR+) |
|
like this
|
|
here you go it also detects fake properties (if they have a space in them,. e.g. no script) - the word to split the contents into common is different in blink - yet to test safari |
|
note: NS lies the same across all elements - and the same probably goes for most extensions e.g. JShelter (I need to test more but lack a profile dedicated to it just yet). So detecting some BS entropy is most likely covered by any one of those elements I think what I will do here is see what ones are super stable in gecko and across OSes and drop them for TZP - and focus on a smaller set - e.g. it would be nice to drop |
it's even faster to use DOMParser |
@abrahamjuliot .. what's going on here?
TZP code
on creepy I get 312 keys hash
b2a71fabon TZP I get 312 keys hash
43c289caso I compared them
results
So why does TZP's first item =
alignand creepy's =versionplease explain yourself, young man! :)
The text was updated successfully, but these errors were encountered: