Closed
Bug 62679
Opened 25 years ago
Closed 24 years ago
Linked Stylesheet not recognised on initial load of browser.
Categories
(Core :: XUL, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
Future
People
(Reporter: kinger, Assigned: hyatt)
Details
Attachments
(1 file)
|
2.31 KB,
text/plain
|
Details |
The content displays, but no style is picked up.
Open a browser using openDialog for example, and pass a HTML page with a linked
stylesheet.
e.g.
window.openDialog("chrome://komodo/content/help/help.xul",
"komodo:help",
"chrome,dialog=no,all",
"chrome://komodo/content/doc/komodo/komodo-doc-getting-started.html");
The stylesheet is linked in HTML as follows:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<LINK REL="stylesheet" TYPE="text/css" HREF="Active.css"></link>
<TITLE>Komodo Documentation</TITLE>
</HEAD>
....
</HTML>
_content.document.styleSheets - does not return anything.
I've tried, amongst other things:
1. Removing DOCTYPE declaration
2. Changing src to full chrome url.
No change.
If I do a reload - no change.
If I open the document then through File->Open File, it *is* picked up.
|
||
Comment 1•25 years ago
|
||
So this only occurs on pages loaded via chrome:// ?
If so, then I'd guess it's because chrome:// is a magical URI, and the paths
you give do _not_ map directly to the file system. Some extra stuff is added,
like your current theme or locale, etc. No?
Hey, what do I know...
|
Reporter | |
Comment 2•25 years ago
|
||
The example I gave was a bit misleading. The same occurs if you open the
page with the Mozilla browser:
window.openDialog("chrome://navigator/content/navigator.xul", .....).
But yes, our custom help browser does have it's own locale .. but inherits most
of it's theme info from global.
The scenario you are describing of it only occuring with pages loaded via chrome
urls does ring a bell though. It would be impractical to change to a file://
url every time.
|
|
Reporter | |
Comment 3•25 years ago
|
||
Okay, this appears to be application (Komodo) specific, but I have more leads.
It is giving the message "Wrong parent style context" (nsFrameManager.cpp).
What exactly does this mean?
I'll create an attachment with the full error output.
|
|
Reporter | |
Comment 4•25 years ago
|
||
|
|
||
Comment 5•25 years ago
|
||
Netscape's standard compliance QA team reorganised itself once again, so taking
remaining non-tables style bugs. Sorry about the spam. I tried to get this done
directly at the database level, but apparently that is "not easy because of the
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
|
||
Comment 6•24 years ago
|
||
My apologies for having neglected this bug for so long...
Reassigned to XPToolkit/XUL.
Assignee: pierre → trudelle
Component: Style System → XP Toolkit/Widgets: XUL
QA Contact: ian → jrgm
|
|
||
Comment 7•24 years ago
|
||
Actually, this bug is not really specific to Komodo. If I add a simple HTML
document which links to a simple stylesheet, and place them in comm.jar so
that the HTML document is chrome://navigator/content/foo.xul, and then open
them with window.openDialog using navigator.xul and passing the chrome url
for 'foo.xul', then ... the linked stylesheet is not applied to the HTML
document.
|
|
Reporter | |
Comment 8•24 years ago
|
||
Okay, so it is more fundamental to mozilla itself. I have not tried to load it
with a non-chrome url. Do you think this is the problem? Let me know if you need
more testing done this end.
|
|
||
Comment 9•24 years ago
|
||
I did try with a non-chrome URL, and that works fine. It seems limited to
opening and HTML document with a linked stylesheet, via a chrome: url.
By the way, is this blocking you in some way?
|
|
Reporter | |
Comment 10•24 years ago
|
||
Well, it's not a major blocker, more of a major inconvenience :)
We have multiple help files with inline style as a workaround, so if we make a
style change, we have to touch every one. Obviously a central location for style
is more desirable.
One possible workaround would be to convert chrome urls to file urls before
loading, though this would involve hardcoding a part of the path which may be
subject to change (though not very often).
|
|
Assignee | |
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Future
|
|
Reporter | |
Comment 12•24 years ago
|
||
I can not re-create this in a cvs version from 2 days ago, with the following
formats:
<LINK rel="stylesheet" href="Active.css" type="text/css">
or
<LINK rel="stylesheet" href="Active.css" type="text/css"></LINK>
You can go ahead and close this off if you are satisfied with your own testing.
|
|
Reporter | |
Comment 13•24 years ago
|
||
Resolving as WORKSFORME. Seeking verification.
|
|
||
Comment 14•24 years ago
|
||
verified in a current trunk build on win32. A stylesheet referenced by a
'chrome://' path is properly loaded and the style applied to the content,
whether that content is HTML or XUL. Thanks Brian (I should have closed
this out myself earlier when you made your prior comment).
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•