UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:63.0) Gecko/20100101 Firefox/63.0

Example URL:
https://jfkthame.github.io/test/bdo.html

Steps to reproduce the problem:
1. Load https://jfkthame.github.io/test/bdo.html
2. Observe the red test line, which uses <bdo dir=auto>

What is the expected behavior?
The content in <bdo> should always have its inherent Unicode directionality overridden and a uniform directionality applied, based on the dir attribute ('ltr' or 'rtl'). The HTML spec explicitly notes that the 'auto' value is NOT valid for the <bdo> element.

https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-bdo-element

As 'auto' is not valid here, the expected behavior would be to apply the inherited LTR directionality to all the content of the <bdo> element.

What went wrong?
Chrome applies the Unicode bidi algorithm to the content of the <bdo> element, so the Arabic letters are rendered RTL, and the digits are rendered LTR. This would be the expected behavior OUTSIDE a <bdo> element, but should be overridden here.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 67.0.3396.87 (Official Build) (64-bit)  Channel: stable
OS Version: OS X 10.13
Flash Version: Shockwave Flash 30.0 r0

Internet Explorer and MS Edge appear to ignore dir=auto on the <bdo> element, as expected.

Firefox resolves the directionality to RTL, based on the text content of the element (which would be correct behavior for dir=auto on other elements, but is arguably a bug here), and then applies that override to all the text.

Thus, the browsers show three entirely different results for the <bdo> element with dir=auto in this testcase:

(1) ignore the invalid attribute, apply LTR override (Microsoft)
(2) resolve dir=auto based on content, apply RTL override (Mozilla)
(3) apply Unicode bidi, ignoring the override altogether (Webkit, Blink)

I believe (1) is most consistent with the spec as it stands. A case could be made for (2), but this would require a spec change to allow it. I cannot see a justification for (3); this makes no sense for an element that is by definition a bidi override. Authors wanting such behavior should probably be using <bdi> or similar.