This is a follow-up to Bug 9911 Comment #12 to check on the behavior of document.dir in the <head> section of a web page.
1. Default values in <head>:
Firefox 184.108.40.206rc3: 'ltr'
MSIE 6: '' (empty string)
WebKit r15465: undefined
2. Both Firefox and MSIE allow document.dir to be set in the <head>, and the value carries over to the body. WebKit does not allow the value to be set, and the value is still undefined in the body.
3. Firefox, MSIE and WebKit all allow the document.dir property to be set in the <body>.
Created attachment 9476 [details]
Created attachment 9477 [details]
Test case as patch
Created attachment 9478 [details]
Firefox 220.127.116.11rc3 test results
Created attachment 9479 [details]
MSIE 6 test results
Darin, I tested production Safari 2.0.4 (419.3) on Mac OS X 10.4.7 (8J135/PowerPC), and it returned an empty string for document.dir in <head> (see test results I'll post soon). That means your change for Bug 9911 caused a regression, which makes this bug (partially) a regression.
I'm adding keywords and changing the priority for now.
Created attachment 9480 [details]
Safari 2.0.4 test results
Created attachment 9481 [details]
WebKit r15465 test results
Created attachment 9484 [details]
Interactive test case
This is an interactive test case that lets you set values on the document.dir and document.body.dir properties. Testing in Firefox 18.104.22.168rc3 and MSIE 6, I found some interesting behavior:
- In both Firefox and MSIE, body.dir overrides document.dir, and they are independent values. In ToT WebKit, the values are linked together (there is no separate document.dir property since its implementation references body.dir).
- The initial value of document.dir is empty in MSIE, but it behaves as if it were set to 'ltr' internally.
- Firefox has an initial value of 'ltr' in document.dir, and only allows valid values to be set on it. It can never be the empty string.
- Both MSIE and Firefox allow body.dir to be set to an empty string.
The regression aspect of this bug is tiny and easily fixed. Returning empty string instead of undefined when there's no body is incredibly simple.
The rest of this bug is more difficult to resolve. Using the body element to hold the direction attribute won't work well if we have to be able to manipulate it before the body element exists.
Covering both issues with one bug report causes the priority of the simple one (regression, P1) to taint the priority of the complex one. So we might need to break this into two.
(In reply to comment #5)
> Darin, I tested production Safari 2.0.4 (419.3) on Mac OS X 10.4.7
> (8J135/PowerPC), and it returned an empty string for document.dir in <head>
> (see test results I'll post soon). That means your change for Bug 9911 caused
> a regression, which makes this bug (partially) a regression.
> I'm adding keywords and changing the priority for now.
Resetting keywords and priority. Will file a new bug for the regression.
(In reply to comment #10)
> Resetting keywords and priority. Will file a new bug for the regression.
Bug 9954 created for the regression.
Created attachment 9504 [details]
Test case #2 as patch
This is work-in-progress test case that tests the rendering of documents in iframes after setting both the document.dir and document.body.dir properties. Note that since WebKit's implementation of those properties is the same value, changing one changes the other (and vice-versa).
All of the tests where the body value should override the document value will have INCORRECT results because of this.
(In reply to comment #12)
> Created an attachment (id=9504) 
> Test case #2 as patch
I should also note that this test case suffers from Bug 9959 (which was found while writing this test case).