[BUG]: _NetWebView2_Navigate() with pdfJS is not waiting for all processing

[mlipok]

What happened?

#85 (comment)

even if you use:

;~ 	$oWeb.Navigate($s_Viewer_URL)
	_NetWebView2_Navigate($oWeb, $s_Viewer_URL, $NETWEBVIEW2_MESSAGE__TITLE_CHANGED, 5000)

then you get:

+> ( NetWebView2Lib UDF : SLN=1560 ) :: [NetWebView2Lib:EVENT: OnTitleChanged]: GUI:[HANDLE:0x00360A52] TITLE: PDF.js viewer
! we're done with navigation, but check how many more messages there are below. SLN=249
+> ( NetWebView2Lib UDF : SLN=1560 ) :: [NetWebView2Lib:EVENT: OnTitleChanged]: GUI:[HANDLE:0x00360A52] TITLE: invoice-plugin-sample.pdf
+> ( NetWebView2Lib UDF : SLN=1560 ) :: [NetWebView2Lib:EVENT: OnTitleChanged]: GUI:[HANDLE:0x00360A52] TITLE: PDF Invoice Example - invoice-plugin-sample.pdf

this means that you are not able to fully wait on the loading process ends.

But I have some Idea on later.

What did you expect to happen?

_NetWebView2_Navigate() should have possibility to define which exact title is expected.

Which steps did you take to reproduce the bug?

check example:
Update 014-pdfJS-Static_PDF_Viewer.au3

using this PR
#85

Screenshots

Version

latest version

Older or unknown version?

No response

Do you want to work on this issue/fix?

Yes

What system are you running?

• Windows 11 (x64)
• Windows 10 (x64)
• Windows 10 (x86)
• other Windows version
• other operating system

Any additional context?

I think it will be related not only to pdfjs but also other cases, and because of that it is so important

[ioa747]

Hi @mlipok, I have checked the issue using your example.

The multiple title changes you see in the log are actually the expected behavior of the pdf.js library (and many other SPAs) as it progressively loads the viewer, then the file, and finally the metadata. The _NetWebView2_Navigate function works correctly reporting every event fired by the browser engine.

I faced a very similar timing challenge in my 005-SaveDemo.au3 example when dealing with multiple microsoft.com redirects. The solution was not to change the way events are reported, but to ensure that the AutoIt script waits until the browser is actually "ready".

The solution is to use the _NetWebView2_WaitForReadyState function I developed, which polls document.readyState until it returns "done":

; Example of functional synchronization:
_NetWebView2_Navigate($oWeb, $s_Viewer_URL)
_NetWebView2_WaitForReadyState($oWeb)

In my tests with your PDF example, this adds a small, necessary wait (about 190ms), ensuring that the document is fully initialized before executing further scripts (such as text extraction).

$oWeb.Navigate($s_Viewer_URL)
_NetWebView2_WaitForReadyState($oWeb)
;~ _NetWebView2_Navigate($oWeb, $s_Viewer_URL, $NETEBVIEW2_MESSAGE__TITLE_CHANGED, 5000)
ConsoleWrite("! we are done with navigation, but check how many more messages are below. SLN=" & @ScriptLineNumber & @CRLF)

MsgBox($MB_TOPMOST, "TEST #" & @ScriptLineNumber, 'Waiting for all PDF messages to be fully loaded by pdf.js')

Question:
Should we consider incorporating the _NetWebView2_WaitForReadyState logic directly into _NetWebView2_Navigate as an optional parameter or as default behavior to make the UDF more 'plug-and-play' for complex scenarios?

[mlipok]

I read this on my phone
Will work in thw evening on ready state feature
Thanks

[mlipok]

mentioned
#89
fixs this issue

please consider close