Make nsHTMLContentSink easier to use

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
13 years ago
9 years ago

People

(Reporter: mrbkap, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
While working on bug 296963, I found that it was really hard to use
nsHTMLDocument and nsHTMLContentSink without doing lots of stuff unrelated to
parsing. I want to make these classes behave sanely if I don't have stuff like a
container (nsIDocShell) to pass.
(Reporter)

Comment 1

13 years ago
Created attachment 198738 [details] [diff] [review]
No containers required
Attachment #198738 - Flags: superreview?(jst)
Attachment #198738 - Flags: review?(jst)
Comment on attachment 198738 [details] [diff] [review]
No containers required

r+sr=jst
Attachment #198738 - Flags: superreview?(jst)
Attachment #198738 - Flags: superreview+
Attachment #198738 - Flags: review?(jst)
Attachment #198738 - Flags: review+
So... why is this defaulting to true?  Given that HTML loads subframes from
content, this will lead to random docshells that are not in a docshell tree
hanging about, and last I checked docshell did not quite deal well with that.
(Reporter)

Comment 4

13 years ago
I still need to work on that bit... Note that we never get here without a
docshell in the real world... only in my world, which cannot use
nsHTMLDocument::StartDocumentLoad for various reasons. I'm still trying to
figure out how the regression tests should handle <script> and <iframe> and friends.
> Note that we never get here without a docshell in the real world

Not even from accessibility?  I seem to recall aaron checked in some code that
parsed HTML to put nicer accessible text (based on title of document linked to,
eg) on links...

Comment 6

13 years ago
(In reply to comment #5)
> > Note that we never get here without a docshell in the real world
> 
> Not even from accessibility?  I seem to recall aaron checked in some code that
> parsed HTML to put nicer accessible text (based on title of document linked to,
> eg) on links...

I haven't checked that in yet. I'll update the trunk patch after the release of
1.5. It's bug 277469.
Ah, that's using its own sink.  OK.
(Reporter)

Updated

10 years ago
Assignee: mrbkap → nobody
Moot now?
Whiteboard: [WONTFIX?]
(Reporter)

Comment 9

9 years ago
Yes.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
Whiteboard: [WONTFIX?]
You need to log in before you can comment on or make changes to this bug.