RESOLVED CONFIGURATION CHANGED 9947
document.dir can't be set in <head> and has no default value
https://bugs.webkit.org/show_bug.cgi?id=9947
Summary document.dir can't be set in <head> and has no default value
David Kilzer (:ddkilzer)
Reported 2006-07-15 21:30:39 PDT
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 1.5.0.5rc3: '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>.
Attachments
Test case (786 bytes, text/html)
2006-07-15 21:36 PDT, David Kilzer (:ddkilzer)
no flags
Test case as patch (1.07 KB, patch)
2006-07-15 21:38 PDT, David Kilzer (:ddkilzer)
no flags
Firefox 1.5.0.5rc3 test results (962 bytes, text/html)
2006-07-15 21:38 PDT, David Kilzer (:ddkilzer)
no flags
MSIE 6 test results (3.18 KB, text/html)
2006-07-15 21:39 PDT, David Kilzer (:ddkilzer)
no flags
Safari 2.0.4 test results (1015 bytes, text/html)
2006-07-15 21:53 PDT, David Kilzer (:ddkilzer)
no flags
WebKit r15465 test results  (1.06 KB, text/html)
2006-07-15 21:55 PDT, David Kilzer (:ddkilzer)
no flags
Interactive test case (819 bytes, text/html)
2006-07-16 06:29 PDT, David Kilzer (:ddkilzer)
no flags
Test case #2 as patch (5.48 KB, patch)
2006-07-16 14:12 PDT, David Kilzer (:ddkilzer)
no flags
David Kilzer (:ddkilzer)
Comment 1 2006-07-15 21:36:52 PDT
Created attachment 9476 [details] Test case
David Kilzer (:ddkilzer)
Comment 2 2006-07-15 21:38:12 PDT
Created attachment 9477 [details] Test case as patch
David Kilzer (:ddkilzer)
Comment 3 2006-07-15 21:38:51 PDT
Created attachment 9478 [details] Firefox 1.5.0.5rc3 test results
David Kilzer (:ddkilzer)
Comment 4 2006-07-15 21:39:11 PDT
Created attachment 9479 [details] MSIE 6 test results
David Kilzer (:ddkilzer)
Comment 5 2006-07-15 21:52:00 PDT
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.
David Kilzer (:ddkilzer)
Comment 6 2006-07-15 21:53:50 PDT
Created attachment 9480 [details] Safari 2.0.4 test results
David Kilzer (:ddkilzer)
Comment 7 2006-07-15 21:55:15 PDT
Created attachment 9481 [details] WebKit r15465 test results
David Kilzer (:ddkilzer)
Comment 8 2006-07-16 06:29:08 PDT
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 1.5.0.5rc3 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). - MSIE allows the document.dir property to be set to an empty string, but retains the last valid value internally. This makes it impossible to know what the actual direction is from JavaScript if document.dir is set, then cleared. - 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.
Darin Adler
Comment 9 2006-07-16 06:30:57 PDT
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.
David Kilzer (:ddkilzer)
Comment 10 2006-07-16 07:09:20 PDT
(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.
David Kilzer (:ddkilzer)
Comment 11 2006-07-16 07:15:56 PDT
(In reply to comment #10) > Resetting keywords and priority.  Will file a new bug for the regression. Bug 9954 created for the regression.
David Kilzer (:ddkilzer)
Comment 12 2006-07-16 14:12:44 PDT
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.
David Kilzer (:ddkilzer)
Comment 13 2006-07-16 14:13:29 PDT
(In reply to comment #12) > Created an attachment (id=9504) [edit] > 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).
Anne van Kesteren
Comment 14 2023-08-23 07:33:42 PDT
This got fixed at some point (and also much better defined in the HTML standard).
Note You need to log in before you can comment on or make changes to this bug.