_WD_GetElementFromPoint + _WD_FrameEnter usage

[mlipok]

Bug report

Describe the bug

_WD_GetElementFromPoint may affect script as it uses _WD_FrameEnter to change frames

How to reproduce

WIP (so far it only points to a possible problem - i think this need more investigation)

Expected behavior

any UDF function which internally is using _WD_FrameEnter to change frames, should back to calling frame.

Screenshots

WIP

Additional context

My intention is to follow your suggestion from here:
#362 (comment)

I have not analyzed or run this code, but a major problem I can foresee is that of maintaining the current browsing context. If I am currently located two levels deep inside frames when calling a function, then I would expect to still be in that same "location" upon the function's return.

Have you given this any consideration? If yes, then how do you plan to address it?

https://developer.mozilla.org/en-US/docs/Web/API/Document/elementFromPoint

System under test

not related

[Danp2]

any UDF function which internally is using _WD_FrameEnter to change frames, should back to calling frame.

Not true in this case because _WD_GetElementFromPoint returns an Element ID that is only valid from within the correct browsing context. AFAIK, you won't be able to interact with or perform any actions on the found element if you automatically return to the prior browsing context.

If you read the remarks in the header, you'll see that the function sets the value of @Extended if the browsing context was changed. The calling script should save / restore the browsing context if needed.

[mlipok]

hm.... interesting

this following part

Local $sScript1 = "return document.elementFromPoint(arguments[0], arguments[1]);"
...
$sElement = _WD_ExecuteScript($sSession, $sScript1, $sParams, Default, $_WD_JSON_Element)

can return any element even <div> .
Additionally it return such element even when there is no frames and only top level document.

So why it is fired:

_WD_FrameEnter($sSession, $sElement)
$iFrame = 1

at least why $iFrame = 1 when there is only one top level document ?

[Danp2]

IDK. The code should have exited prior to that point if there wasn't a frame involved. It shouldn't be too difficult for you to debug. 😃

[mlipok]

I will test ASAP.

[mlipok]

You can assign this to me.

[Danp2]

@mlipok Are you still looking into this or can we close it?

[mlipok]

give some more time.
Max 2 weeks

[Danp2]

@mlipok Any update?

P.S. Shouldn't this line be checking for "frame" instead of "iframe" so that both element types are detected? That's the only reason to use StringInStr, correct?

au3WebDriver/wd_helper.au3

Line 554 in 951ace1

If Not StringInStr("iframe", $sTagName) Then

[mlipok]

Lets stick to current Pull Request.
When we accompilish PR's then I review issues and start working on them.

[mlipok]

I use:
https://stackoverflow.com/a/34348306/5314940

onmousemove = function(e){console.log("mouse location:", e.clientX, e.clientY)}

to track mouse and start testing this issue

[mlipok]

@mlipok Any update?

P.S. Shouldn't this line be checking for "frame" instead of "iframe" so that both element types are detected? That's the only reason to use StringInStr, correct?

au3WebDriver/wd_helper.au3

Line 554 in 951ace1

If Not StringInStr("iframe", $sTagName) Then

yes
Please take a look on: #450

[mlipok]

Expected behavior

any UDF function which internally is using _WD_FrameEnter to change frames, should back to calling frame.

this is still valid

[mlipok]

I mean that we should add option to

1. automatically get _WD_FrameList()
2. check which Frame is active (before _WD_FrameEnter)
3. back to back to the same Frame (on function Exit)

[Danp2]

This could be done, but there are a few problems with your suggestion --

• IMO using _WD_FrameList would be overkill.
• It would also create the scenario described above
• It would require the function to also return the frame's Element ID, which would be used to switch back to the correct browsing context for the Element ID found by this function.

I may have a solution for the above.

[Danp2]

@mlipok See #451. Untested thus far so YMMV. 😉

[mlipok]

I see getcontext But how to set or switch to desired context ?

[Danp2]

_WD_FrameEnter was my initial thought, but I see this would only work with frames at the current level.

Wouldn't your solution require multiple calls to _WD_FrameList (once before determining the element from point and once after determining the element from point)?

Edit: After some testing, I see that _WD_FrameList would only need to be called once.

[Danp2]

@mlipok Were you ever able to reproduce this issue?

Edit: Or is that what you are looking at here?

[Danp2]

@mlipok Any feedback on the above?

[mlipok]

ASAP, keep waiting.

[Danp2]

@mlipok I've fixed a few issues with _WD_GetElementFromPoint in #478, but I haven't been able to reproduce your scenario where $iFrame = 1 when there aren't any frames. My plan is to close this issue unless you can provide a reproducer.

[mlipok]

unless you can provide a reproducer.

Asap, few days

[Danp2]

We can reopen if you can reproduce.

[mlipok]

Recently we did some new findings/modifications here:
#490
and here:
#488

Is this somehow related ?

[Danp2]

Not AFAIK.