Closed Bug 254536 Opened 20 years ago Closed 20 years ago

[FIX]view-source sometimes renders in quirks mode

Categories

(Core Graveyard :: View Source, defect, P2)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8alpha3

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Details

(Keywords: perf)

Attachments

(1 file)

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...
Attached patch PatchSplinter Review
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?
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.
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+
Fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Keywords: perf
Product: Browser → Seamonkey
Product: SeaMonkey → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: