Closed Bug 255538 Opened 20 years ago Closed 20 years ago

CSS error reports' URL wrong for style element/attribute when base href used

Categories

(Core :: CSS Parsing and Computation, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.8alpha4

People

(Reporter: timeless, Assigned: dbaron)

References

()

Details

(Whiteboard: [patch])

Attachments

(2 files, 1 obsolete file)

Error: Expected ',' or '{' but found '/'.  Ruleset ignored due to bad selector.
Source File: http://personal.fidelity.com/
Line: 5

Problem, the page was https://www.fidelity.com/
style sheets only store one url, and because they can do @import, it pretty much
has to be the one relative to which any @imports will be resolved, in this case
that's http://personal.fidelity.com/. I tried passing the document url as an
extra param through to the error managing object, but that path got called way
too often and i paniced.

so instead, here's a bug for the problem. if we don't fix it before we turn on
the error reporting for debug builds, we'll get lots of bugs complaining about
the confused filename reports.
Blocks: 65469
Summary: Inline style (both kinds) on a page with a base href incorrectly blame → CSS error reports' URL wrong for style element/attribute when base href used
Attached file testcase
Attachment #158337 - Attachment is obsolete: true
Attachment #158368 - Flags: superreview?(bzbarsky)
Attachment #158368 - Flags: review?(bzbarsky)
Comment on attachment 158368 [details] [diff] [review]
patch

>Index: content/html/style/src/nsCSSLoader.cpp

>+    // XXXldb Should we really be doing this if aURI is non-null?  Shouldn't
>+    // we wait to get the URI from the channel?

We did that in the first iteration of the "get URIs from channel" patch. 
Problem is, sometimes the channel doesn't come back (or is never even opened)
and we end up with a not-really-inited sheet that crashes.  Just remove this
XXX comment.

>Index: content/html/style/src/nsCSSParser.cpp
>@@ -634,25 +637,25 @@ CSSParserImpl::ParseStyleAttribute(const

>+  rv = InitScanner(input, aBaseURL, 1, aBaseURL); // XXX line number & URLs

File a followup bug on this?  This shouldn't be that hard to fix.

>@@ -699,25 +702,25 @@ CSSParserImpl::ParseAndAppendDeclaration

>+  rv = InitScanner(input, aBaseURL, 1, aBaseURL); // XXX line number & URLs

Same.

>@@ -757,25 +760,25 @@ CSSParserImpl::ParseRule(const nsAString

>+  rv = InitScanner(input, aBaseURL, 1, aBaseURL); // XXX line number & URLs

And same.

>@@ -816,25 +819,25 @@ CSSParserImpl::ParseProperty(const nsCSS

>+  rv = InitScanner(input, aBaseURL, 1, aBaseURL); // XXX line number & URLs

And this.  Probably one bug for all of them.

r+sr=bzbarsky
Attachment #158368 - Flags: superreview?(bzbarsky)
Attachment #158368 - Flags: superreview+
Attachment #158368 - Flags: review?(bzbarsky)
Attachment #158368 - Flags: review+
Fix checked in to trunk, 2004-09-09 23:43/45 -0700.

Filed bug 258707 (XXX comments in comment 4) and bug 258708 (a few
s/BaseURI/SheetURI/ where I was too conservative in this patch) as followup.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: [patch]
Target Milestone: --- → mozilla1.8alpha4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: