Closed
Bug 414856
Opened 17 years ago
Closed 17 years ago
Firefox 2.0.0.12 RC1 breaks Stylish with "TypeError: stylesheet has no properties"
Categories
(Core :: XML, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jason.barnabe, Assigned: smaug)
References
Details
(4 keywords)
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
sicking
:
review+
sicking
:
superreview+
dveditz
:
approval1.8.1.12+
|
Details | Diff | Splinter Review |
(deleted),
text/html
|
Details |
With Stylish 0.5.3 and Firefox 2.0.0.12 RC1:
1. Click on the Stylish icon, Write Style, For this URL...
2. Preview
Result: TypeError: stylesheet has no properties
This worked with 2.0.0.11.
I'm the author of Stylish and I can make changes to it if required.
Flags: blocking1.8.1.12?
Reporter | ||
Comment 1•17 years ago
|
||
Stylish is trying to get a nsIDOMDocumentStyle from a string of CSS text. To do this, it:
1. Creates a document: document.implementation.createDocument(stylishCommon.XULNS, "stylish-parse", null)
2. Appends a link element with a data URI to the document's document element.
3. Gets a stylesheet object out of the document: doc.QueryInterface(Components.interfaces.nsIDOMDocumentStyle).styleSheets[0]
4. Checks to make sure it's done loading. It's expecting stylesheet.cssRules.length to throw NS_ERROR_DOM_INVALID_ACCESS_ERR if it's not done. Instead, 'stylesheet' is undefined.
Reporter | ||
Comment 2•17 years ago
|
||
'stylesheet' never gets defined, even on subsequent checks.
Reporter | ||
Updated•17 years ago
|
Keywords: regression
Comment 3•17 years ago
|
||
Olli, could this be a regression from bug 393762?
Comment 4•17 years ago
|
||
Jason, could you try these two builds? (before/after bug 393762)
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008-01-22-04-mozilla1.8/
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008-01-23-03-mozilla1.8/
Reporter | ||
Comment 5•17 years ago
|
||
2008-01-22-04-mozilla1.8 - Bug not present
2008-01-23-03-mozilla1.8 - Bug present
Assignee | ||
Comment 6•17 years ago
|
||
Any chance to get a minimal testcase, attached using "Add an attachment"
Assignee | ||
Comment 7•17 years ago
|
||
Haven't yet tested, but my guess is that since loading external files from
data document (which are now created when .createDocument is used) isn't
allowed anymore, loading stylesheets using a data document doesn't work either.
Assignee | ||
Comment 8•17 years ago
|
||
So this is a regression from bug 382636.
Do we want to allow loading external files on branch, but perhaps not on trunk?
... I need to still verify that that is the case here.
Assignee | ||
Comment 9•17 years ago
|
||
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → Olli.Pettay
Assignee | ||
Comment 10•17 years ago
|
||
Do we want to use this? Jonas, bz, anyone?
Doesn't regress Bug 393762 or Bug 393761
Attachment #300432 -
Flags: review?(jonas)
Updated•17 years ago
|
Status: NEW → ASSIGNED
Component: General → XML
Product: Firefox → Core
QA Contact: general → xml
Version: 2.0 Branch → 1.8 Branch
Assignee | ||
Comment 11•17 years ago
|
||
Opera gives the same result as 2.0.11, Safari same as trunk
Attachment #300429 -
Attachment is obsolete: true
Comment 12•17 years ago
|
||
I thought we already set createDocument() documents to be data documents... If we don't, that seems like a bug.
I'm not sure about the security aspect of it, though. If it's safe, it might indeed make sense to revert that part for compat reasons.
Assignee | ||
Comment 13•17 years ago
|
||
No we didn't set .createDocuments as data documents.
It is IMO a bug, which is now fixed both on branch (sort of accidentally) and on
trunk (on purpose).
The extension must be changed for FF3, but during FF2 it is better to not change
the behavior unless absolutely needed.
Attachment #300432 -
Flags: superreview+
Attachment #300432 -
Flags: review?(jonas)
Attachment #300432 -
Flags: review+
Assignee | ||
Updated•17 years ago
|
Attachment #300432 -
Flags: approval1.8.1.12?
Comment 14•17 years ago
|
||
It's not just the extension, the testcase shows this change affects web content. Dunno if anyone uses it, but it's definitely a potentially web-breaking change not just an addon problem.
Comment 15•17 years ago
|
||
Comment on attachment 300432 [details] [diff] [review]
revert back the old behavior
approved for 1.8.1.12, a=dveditz for release-drivers
Attachment #300432 -
Flags: approval1.8.1.12? → approval1.8.1.12+
Assignee | ||
Comment 16•17 years ago
|
||
Jason, could you please try next nightlies. Thanks!
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: fixed1.8.1.12,
testcase
Resolution: --- → FIXED
Assignee | ||
Comment 17•17 years ago
|
||
Checked in to GECKO181_20080128_RELBRANCH and MOZILLA_1_8_BRANCH
Updated•17 years ago
|
Keywords: fixed1.8.1.13
Assignee | ||
Comment 19•17 years ago
|
||
To test the current trunk behavior? Or branch behavior?
Assignee | ||
Comment 20•17 years ago
|
||
I guess trunk. That is IMO what we want, or otherwise we should allow
also image loads etc on data documents.
Updated•17 years ago
|
Flags: blocking1.8.1.12? → blocking1.8.1.12+
Comment 21•17 years ago
|
||
The primary bugs to regression test are of course bug 393762 and bug 393761.
This will, of course, regress bug 382636 since this bug is basically about backing that one out. That is expected and OK for the 1.8 branch.
Make sure it doesn't regress old bug 325005 (which checks the "loadedAsData"
flag).
Blocks: 382636
Comment 22•17 years ago
|
||
This is fixed in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/2008013015 Firefox/2.0.0.1. I've verified it.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1.12 → verified1.8.1.12
Updated•17 years ago
|
Flags: blocking1.8.1.12+ → blocking1.8.1.12?
Updated•17 years ago
|
Flags: blocking1.8.1.12?
Updated•17 years ago
|
Flags: blocking1.8.1.12+
Verified FIXED using Bonsai:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=shipped-locales&branch=MOZILLA_1_8_BRANCH&root=/cvsroot&subdir=/mozilla/browser/locales&command=DIFF_FRAMESET&rev1=1.1.4.18&rev2=1.1.4.19
Replacing fixed1.8.1.13 keyword with verified1.8.1.13.
Keywords: fixed1.8.1.13 → verified1.8.1.13
(In reply to comment #23)
> Verified FIXED using Bonsai:
>
> http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=shipped-locales&branch=MOZILLA_1_8_BRANCH&root=/cvsroot&subdir=/mozilla/browser/locales&command=DIFF_FRAMESET&rev1=1.1.4.18&rev2=1.1.4.19
>
> Replacing fixed1.8.1.13 keyword with verified1.8.1.13.
Commented in the wrong bug, sorry, restoring fixed1.8.1.13 keyword.
Keywords: verified1.8.1.13 → fixed1.8.1.13
Comment 25•17 years ago
|
||
This is verified for 1.8.1.13 as well.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/2008031114 Firefox/2.0.0.13
Keywords: fixed1.8.1.13 → verified1.8.1.13
You need to log in
before you can comment on or make changes to this bug.
Description
•