New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 801497 link

Starred by 1 user
Status: WontFix
Owner:
█ yzshen@chromium.org
Last visit > 30 days ago
Closed: Jan 2018
Cc:
█ ke...@intel.com
mlamouri@chromium.org
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Possible to mock associated interface impl in JS for layout tests?

Project Member Reported by blundell@chromium.org, Jan 12 2018 
Hi Yuzhu,

The desire to mock an *associated* interface impl in JS for BLink's layout tests is arising. See the discussion here: https://chromium-review.googlesource.com/c/chromium/src/+/848735/4/content/shell/test_runner/mock_screen_orientation_client.h#26.

I can't claim to be very familiar with the issues involved here. Is this already possible? If not, is it straightforward to make this possible, or should that CL proceed as Ke He is currently developing it with a TODO on this bug?

Obviously, if you need more information to understand the issues at hand, don't hesitate to let us know. Thanks!

I'm marking as P-2 just to get a resolution to allow that CL to move forward. If the issue isn't straightforward to resolve, then actually adding this support is not a P-2; we can move forward on the CL without it.

Comment 1 by yzshen@chromium.org, Jan 12 2018 

Hi, Colin.

The concept of "associated" interfaces lives purely at the bindings layer (as opposed to the mojo system layer). It is basically using multiple routing IDs over the same message pipe. Therefore, there is no current way to let associated interfaces of the same message pipe live across C++ and JS code -- because the API between C++/JS is the mojo system API. And I doubt that the benefit of adding such support outweighs the cost.

If you want to mock an associated interface in JS, the only possible way at the moment is to intercept the "master" interface (which owns the message pipe) in JS and then you can intercept the associated interface when the master interface (transitively) passes the associated interface endpoint. But I think in this case, the master interface is actually the entire IPC channel so that is unrealistic.

I see that there is already a way moving forward. I lean towards to closing this bug as wontfix. Please let me know if you don't think that makes sense and would like to further discuss potential solutions.

Thanks!

Comment 2 by blundell@chromium.org, Jan 15 2018

Status: WontFix (was: Assigned)
Thanks, Yuzhu! Makes sense.
►

Sign in to add a comment