Closed
Bug 254536
Opened 21 years ago
Closed 21 years ago
[FIX]view-source sometimes renders in quirks mode
Categories
(Core Graveyard :: View Source, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.8alpha3
People
(Reporter: bzbarsky, Assigned: bzbarsky)
Details
(Keywords: perf)
Attachments
(1 file)
1.68 KB,
patch
|
rbs
:
review+
rbs
:
superreview+
|
Details | Diff | Splinter Review |
To be precise, it renders in the mode of the original page. That's poor for
perf, since classname CSS matching is much faster in standards mode (it doesn't
have to do case-insensitive crap).
I have a hack to fix that...
![]() |
Assignee | |
Comment 1•21 years ago
|
||
![]() |
Assignee | |
Comment 2•21 years ago
|
||
Comment on attachment 155338 [details] [diff] [review]
Patch
rbs, what do you think?
Attachment #155338 -
Flags: superreview?(rbs)
Attachment #155338 -
Flags: review?(rbs)
Somehow I cannot quite convince myself that all is clear here. We want a quirks
document to be parsed in quirks mode -- regarless the fact that the sandwitching
of view-source is always neat and can be considered in standards mode. (The
caveat is that the sandwitching needs the inner quirks parsing to deal with a
quirks document.) Won't your trick break this basic constraint?
![]() |
Assignee | |
Comment 4•21 years ago
|
||
rbs, my patch sets the mode to standards on the parser context only during the
function call that sets the compatibility mode on the document (which will be
propagated to things like the style system and layout).
So the parser (tokenizer and DTD) both see the document in quirks or standards,
as appropriate. The rest of gecko (content sink, document, and layout) see it
in standards. Which is fine, because everything after the DTD is seeing the
document that the view-source DTD generates.
![]() |
Assignee | |
Updated•21 years ago
|
Priority: -- → P2
Summary: view-source sometimes renders in quirks mode → [FIX]view-source sometimes renders in quirks mode
Target Milestone: --- → mozilla1.8alpha3
Comment on attachment 155338 [details] [diff] [review]
Patch
r+sr=rbs
OK, go it. I looked at the source of
HTMLContentSink::WillBuildModel() and indeed your patch achieves what you
documented above. No way to get the document in the view-source side. Couldn't
think of anything better / less-invasive.
Might have been possible to test the parser command in
HTMLContentSink::WillBuildModel(). . But that is of dubious value. Your patch
keeps things on the view-source side.
Attachment #155338 -
Flags: superreview?(rbs)
Attachment #155338 -
Flags: superreview+
Attachment #155338 -
Flags: review?(rbs)
Attachment #155338 -
Flags: review+
![]() |
Assignee | |
Comment 6•21 years ago
|
||
Fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•