Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid “Unspecified Error” in MS Edge when accessing `document.activeE… #4393

Closed
wants to merge 1 commit into from
Closed

Conversation

jdalton
Copy link
Contributor

@jdalton jdalton commented Nov 16, 2016

This PR avoids a tricky “Unspecified Error” in MS Edge 14 when accessing
document.activeElement from inside an iframe.

@@ -58,17 +58,15 @@ export function contains(parent, child) {
} while (child = child.parentNode)
}

export let activeElt = function() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the function forking because it seemed like overkill.

// Older versions of IE and sometimes Edge throws unspecified error when touching
// document.activeElement in some cases (during loading, in iframe)
try {
let activeElement = document.activeElement
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it still work when you only wrap the first access to document.activeElement in a try? Non-trivial code wrapped in error-swallowing try/catch scares me, since when someone introduces a bug there, we probably won't notice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll check it out. What's interesting is the old fallback for IE9 didn't have the loop logic.

Copy link
Contributor Author

@jdalton jdalton Nov 16, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marijnh
Do you know if any of the documents are created with DOMParser or the result of an XHR?

I'm triaging the bug from the MS Edge side and trying to narrow down the Unspecified Error which is a fallback error for when things go totally wonky.

Copy link
Contributor Author

@jdalton jdalton Nov 16, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marijnh
Sorry for more q's, but when is there a root property on an element?
Is this something CodeMirror adds?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The loop is to 'break out' of shadow DOMs (which old IE's don't support, hence it was missing from the other implementation)

@jdalton
Copy link
Contributor Author

jdalton commented Nov 17, 2016

@marijnh

Ok I found the issue.

By whatwg spec document.activeElement will be the current focusable element. If non is active it will be document.body. If document.body isn't available then it should be document.documentElement or null (all browsers just return null).

However, in Edge in an iframe, if activeElement is supposed to be document.body and it's not available it will throw Unspecified Error. Out of the iframe it will result in null.

Update:
Oh snao! It turns out it will do that in Edge, IE 11, IE 10, IE9, IE8... I've updated the code comment to describe the issue better.

@marijnh
Copy link
Member

marijnh commented Nov 18, 2016

Thanks! Merged as 69669e4.

// IE < 10 will throw when accessed while the page is loading or in an iframe.
// IE > 9 and Edge will throw when accessed in an iframe if document.body is unavailable.

Could it be that these are actually the same case? It was observed 'during loading' before, but most likely that was just because no body was available.

@marijnh marijnh closed this Nov 18, 2016
@jdalton jdalton deleted the activeElement branch November 18, 2016 15:11
@jdalton
Copy link
Contributor Author

jdalton commented Nov 18, 2016

Could it be that these are actually the same case? It was observed 'during loading' before, but most likely that was just because no body was available.

They could be similar.
I wasn't sure if IE < 10 may also error out of an iframe while the page is loaded so I left that bit in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants