Tried testing the issue on reported chrome version #70.0.3538.77 using Windows 10 by following below steps.

Steps:
=====
1.Launched chrome.
2.Downloaded and opened "pseudo-demo.html" file.
3.Navigated to Devtools->Console.
4.Under the console tab executed "window.getComputedStyle()".
5.Observed error-"Uncaught TypeError: Failed to execute 'getComputedStyle' on 'Window': 1 argument required, but only 0 present.".

Attached screencast for reference.
@reporter: Could you please review attached screencast and let us know if anything is being missed here. Request you to provide screencast/screenshot of the issue so that it would be really helpful for further triaging of the issue.
Thanks.! 

Deleted: 901978.mp4 1.2 MB

	901978.mp4 1.2 MB View Download

Maybe my instructions were not clear. The demo that I attached runs the code for you. You don't need to actually run "window.getComputedStyle()" in the console.

There is no "error" in the technical/traditional sense. I'm pointing out that the behaviour of the script in that demo is not producing the desired result.

If you want to do the steps as shown in your screencast, then run the following commands on that page:

console.log(window.getComputedStyle(document.querySelector('div'), '::before').color);
console.log(window.getComputedStyle(document.querySelector('div'), '::fake-pseudo').width);

Those return results on the 'div' element but they should not. they should return results on the non-existen "::before" and "::fake-pseudo" elements. Which means they should return an empty string in both cases, not an error, and certainly not the CSS of the element that was not targeted.

Does that make it more clear?

So just to emphasize: What you see in the console in your screencast is the incorrect behaviour that I'm reporting. 

Sorry, just to make that last sentence more clear: In the console you see two lines. One that says "rgb(0, 0, 255)" and one that says "1264px". Those two message should instead each be an empty string, not an actual value.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Actually, thinking about this some more, I think the correct behaviour should be an error. For example, the following code will produce an error:

window.getComputedStyle(document.querySelector('banana')).width

This is because the "banana" element doesn't exist. When adding a second argument to getComputedStyle(), it's supposed to target a pseudo-element. So if that pseudo-element doesn't exist, the browser should similarly throw an error. An empty string would be another way of handling it but it's misleading to the developer to not get an error in a case like this. Either way, I don't believe the current behaviour is the correct behaviour.

Rune, what's your take on this?

Resolved to throw in https://github.com/w3c/csswg-drafts/issues/2149 but I don't think anyone does that yet.

Chrome, Safari and Edge all return the parent element computed style for unknown pseudo elements. Firefox empty string, even if they claimed to throw during the CSSWG F2F. Without a "::" prefix, even Firefox returns the parent element computed style.

There's definitely a compat risk with changing anything here.

Gecko used to throw at getPropertyValue time iirc, I may have inadvertently changed that as part of the work to make us more compatible in cases with display: none iframes and such.

There are two different cases here. That resolution only covers one of them iiuc, and Gecko has different behavior for them.

 * Known but non-existent pseudo-element (i.e. ::before that doesn't match any rules or such). Gecko would Mint a style inheriting from the parent element's style rather than just returning the parent element unchanged. I think this should be a somewhat uncontroversial change.

 * Unparsable pseudo (either unknown or private or something). In that case that resolution says we should throw, which seems more useful than just returning the element's style, but I agree there's a non-zero compatibility risk here.