WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Test case as patch
(1.07 KB, patch)
2006-07-15 21:38 PDT
,
David Kilzer (:ddkilzer)
no flags
Details
Formatted Diff
Diff
Firefox 1.5.0.5rc3 test results
(962 bytes, text/html)
2006-07-15 21:38 PDT
,
David Kilzer (:ddkilzer)
no flags
Details
MSIE 6 test results
(3.18 KB, text/html)
2006-07-15 21:39 PDT
,
David Kilzer (:ddkilzer)
no flags
Details
Safari 2.0.4 test results
(1015 bytes, text/html)
2006-07-15 21:53 PDT
,
David Kilzer (:ddkilzer)
no flags
Details
WebKit r15465 test results
(1.06 KB, text/html)
2006-07-15 21:55 PDT
,
David Kilzer (:ddkilzer)
no flags
Details
Interactive test case
(819 bytes, text/html)
2006-07-16 06:29 PDT
,
David Kilzer (:ddkilzer)
no flags
Details
Test case #2 as patch
(5.48 KB, patch)
2006-07-16 14:12 PDT
,
David Kilzer (:ddkilzer)
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
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.
Top of Page
Format For Printing
XML
Clone This Bug