Eugene, by "pretty bad", is the problem that it's accessing APIs we don't want to expose (raw WKWebView)? Or is there something else wrong with it (incorrect, flaky, ...)?

Sorry for "pretty bad". Walking through the view hierarchy and grabbing a delegate is an encapsulation violation. Encapsulation violations are form of technical debt because the test relies on internal implementation.

This WKWebView is not a part of web layer, so the bug is not about layering violation.

Can we prioritize this? It's a serious layering violation.

I don't really know anything about this bug, Eugene, would you be a better owner for this bug?

|StaticHtmlViewController* GetStaticHtmlView(web::WebState* web_state)| is a part of Chrome EG Integration testing framework, which I do not own. 

GetStaticHtmlView makes assumptions about view hierarchy and existence of WKWebView. I don't know the purpose of GetStaticHtmlView, but GetStaticHtmlView implementation violates layering and encapsulation. Maybe we should rewrite GetStaticHtmlView or maybe we should just throw GetStaticHtmlView away.

Hey Eugene,

I think there have been some confusions around who are currently the owners of EG framework. baxley@ was clearly the owner, but his leaving shouldn't leave Menglu and I being the default maintainer of the EG framework, but whether we want to or will be is a different thing, and it's also pretty unfortunate that the team hasn't reached to Menglu or me or John to discuss this.

Anyway, I'm happy to voluntarily cover some of the bugs balxey@ left over, but I don't think I'll be able to get to this one any time soon, so I'm marking it as available for now.

This API is only used in ReadingList tests. Olivier, is this something that you can fix?

Hi

We need an equivalent of WaitForWebViewContainingText for distilled page.
What makes the static page implementation worse than the actual webView implementation?

Thanks Oliver for clarifying the reason why GetStaticHtmlView exists.

If the question was: "what's wrong with the following code:
|WKWebView* web_view = base::mac::ObjCCast<WKWebView(web_state_view.subviews.firstObject);|?"

Then the answer is:

This code makes assumptions about 2 things which are strict implementation details:
 - view hierarchy create by web controller
 - the fact that StaticHtmlViewController is WKNavigationDelegate
These assumptions will not allow to refactor NativeContent usage, without breaking the tests.



Now that I understand why GetStaticHtmlView exists, I think we can put this bug on hold until we actually start repealing NativeContent.