rhardih/ekill

Seperate branches for chrome and firefox?

duart38 opened this issue · 10 comments

duart38 commented

Hey again.

So i've found this (possibly) more efficient way of replacing already removed elements on a page using XPath

see here my fork .
But it seems that this approach only works on chrome due to the toElement being used in the mouseEvent callback.

My question is .. can we have a separate version for Chrome/Firefox so we can have tailored code for both?

Yoric commented

What's that toElement, exactly? I can't find it anywhere in the specs.

duart38 commented

@Yoric take a look at this stackoverflow answer

you can also look at my fork.. for some reason xpath does not seem to work with target or others

Yoric commented

Yeah, I find "fromElement and toElement are IE non-standard ways to obtain the relatedTarget"

  • 👍1
duart38 commented

hmmm give me a second ill hop in the project and test some more things out asap

Yoric commented

I confirm that I can't find any trace of toElement in the spec.

rhardih commented

There's already a separate firefox branch, due to persistent: false, causing a warning in Firefox.

Ideally I'd really like to keep the codebase diff as minimal as possible between the two, but some minor differences is inevitable.

I don't think we need to bring out guns as big as XPath for this.

Here's the current approach I'm playing around with:

Since the DOM is a tree structure, we can always uniquely identify any element on a page by a path from the root node to that element.

Generating such a path can be done by going up the parentElement chain whilst keeping a list of visited nodes along with any identifying attributes needed. Then finally reversing that list.

Also, we need to consider ordering and merging of paths in that data structure. E.g. consider first clicking some inner part of a popup, because you didn't quite catch the "outer" element the first time around, and then subsequently clicking the remaining outer container. In this case, we don't want to save the first element because it was a child of the second.

Another thing we need is domain wide recurrences. Most cookie notices etc. pops up on all sub paths of a given domain; e.g.

nytimes.com/some/article/foo
nytimes.com/another/article/bar

Will both present the same popup. In that case, we need to have a "merged" catch-all key.

Example:

We visit the first article and then we save the path:

nytimes.com
 - /some/article/foo
  - specific
   - path
    - to
     - element

We visit the next article, but instead of having this:

nytimes.com
 - /some/article/foo
  - specific
   - path
    - to
     - element
 - /another/article/bar
  - specific
   - path
    - to
     - element

We should wind up with something like this:

nytimes.com
 - /*
  - specific
   - path
    - to
     - element

I'll open up a PR from the grudge branch as soon as I have something more concrete and we can continue the discussion there. 👍

Yoric commented

I don't think we need to bring out guns as big as XPath for this.
[...]
Since the DOM is a tree structure, we can always uniquely identify any element on a page by a path from the root node to that element.

Generating such a path can be done by going up the parentElement chain whilst keeping a list of visited nodes along with any identifying attributes needed. Then finally reversing that list.

Doesn't this smell a little like reimplementing XPath without platform support?

rhardih commented

@Yoric We could generate an XPath query from the approach I propose as well. We need to generate a selector no matter what. It's just a matter of document.evaluate() vs. document.querySelector, where the latter has a much simpler api.

duart38 commented

Another thing we need is domain wide recurrences. Most cookie notices etc. pops up on all sub paths of a given domain; e.g.

i think i already implemented this? or was it after the merge?