This looks like out of scope for TE, hence adding the respective label for it to  triage further.

govind@ - Could you help to triage this issue?    

Ligi, could you ptal and see if you can repro and bisect if possible.

Would you mind providing an html testcase for the ease of reproducing and bisecting.

Also looping to wfh@ who commented on original issue- "  Issue 414989  "

I suppose that this is a general problem, as it did not work on any tested page (e.g. www.google.com, www.spiegel.de). Please try these.

I recently tried to further investigate the issue. After updating to the current Chrome version (59.0.3071.86) and editing the C++ test case, the nature of the error changed. I tested it with the page "www.spiegel.de".

If Chrome 32 bit is installed, I get hr = S_OK, if my executable is compiled as 32 bit. In all other cases (Chrome 32b, exe 64b; Chrome 64b, exe 64b; Chrome 64b, exe 32b) I receive hr = REGDB_E_CLASSNOTREG.

I attached my modified C++ test case.

Deleted: chrome-test-v2.zip 10.2 KB

chrome-test-v2.zip 10.2 KB Download

Is this still reproducing on Chrome 71?

I tested it with version 71.0.3562.2 under Windows 10 and all 4 combinations yielded hr = E_INVALIDARG again.

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Thats realy on short notice...

I just tested it again with versions 32-bit: 73.0.3642.1 and 64-bit: 73.0.3642.0. In all 4 cases the unexpected hr = E_INVALIDARG still occurs.

I was actually confused for a while because I thought this was an x64 vs x86 issue.

Digging into this a bit, I think the issue is that we have never supported ISimpleDOMNode on the entire window, only for the web content.

Try searching the accessibility tree for the first object with ROLE_SYSTEM_DOCUMENT, corresponding to the main web area.

QueryService for ISimpleDOMNode should succeed there.

It would also help to understand what you're hoping to accomplish with ISimpleDOMNode. It's not widely used now and I'd prefer if we could drop it.

Hi,

thank you for looking into this.

Apparently what you mention was indeed an error on my side, at least for the last two tests namely the one from December the 17th 2018 and the one on September the 27th 2018.

I also noticed that I had previously switched from Windows 7 to Windows 10 and while doing these tests today again on Windows 10, at least the QueryInterface on the accessable worked as expected.

However, the QueryService call still fails even on Windows 10. The resulting error code is 0x8007007e and my debugger shows this as error code as "HRESULT_FROM_WIN32(ERROR_MOD_NOT_FOUND)", which is kind of new to me too.

Initially on my previous installation of Windows 7 I could indeed observe different behaviour according to the patterns regarding architecture described above in my initial post and the one described on June the 12th 2017. In those test scenarios I must have choosen the correct window, simply because the call to QueryInterface on the accessable succeeded.

Amongst other things, we hoped to get easy access to the current sites HTML as soon as an implementation for "STDMETHODIMP get_innerHTML(BSTR* innerHTML)" is provided. Then we could handle chrome in the same way we currently handle firefox. We wanted to do this without writing ourself a chrome plugin that has access to the HTML and then to transfer the HTML via IPC.

I hope you can reproduce the issue.

P.S.:
I attached the modified test case which I used this time.

Deleted: chrome-test-v3.zip 11.5 KB

chrome-test-v3.zip 11.5 KB Download

Ah, it sounds like we actually have two issues. Even if you do get ISimpleDOM, we don't implement get_innerHTML, because it's too expensive. COM calls are synchronous and we'd have to freeze the whole UI while computing the whole thing as a single string. If we wanted to support this, I think we'd need an async API.

Can you give me more context on what you're trying to do? Is there any possibility that using WebDriver or the Chrome remote debugging protocol would meet your needs instead?

Are you developing software that runs on your own, trusted machine? Or software that will run on customer / user machines?

Thank you for your answer.

We are developing software that runs on customer user machines.


Our software provides help and information material based on the current context. The context beeing in the most cases the current application the user has focused. But because web browsers can display all sorts of things and we want to display help for the user depending on the content, there can not be a single context for each browser, but instead we have to determine the browsers content and determine the context based on that.

In some cases the window title or the url of the current document is sufficient to get the context granularity the customer wants. However in a significant portion of cases, they have non trivial web interfaces where the customer needs a more finely grained selection of context in order for us to provide the relevant helper documents. Some of them are multi paged applications, but most of them are actually single page based web pages. The thing both of them have in common: Those applications were not designed to provide their context in an accessibility friendly way. Like previously stated, in some cases we do have luck and we can only use the information given by the url, but quite a lot other cases remain.

In these cases we offer our customers a customizing, specific for their application. In that customizing we basically parse the HTML via regular expressions to receive information to be able to finer differentiate the context the user is currently in this web application.

This method is stream lined over the browsers Internet Explorer and Firefox, because they provide a way to get the HTML as a whole string via some kind of api (Firefox even over ISimpleDom). So this often requested scenario we have to say to our customers, that for these kind of customizings we can not support chrome at the moment.


WebDriver or the Chrome remote debugging protocol seem to not fit our needs. However I would have to further assess them. I currently do not have time for that, I will take a closer look at them when I do have time.


Please note, that I am on vacation the next few days. I should be back on Tuesday the 22th of January 2019.