Closed
Bug 77539
Opened 24 years ago
Closed 23 years ago
Crash when viewing a message with www.marketwatch.com attached; M09 crash [@ nsStreamConverter::Init ]
Categories
(MailNews Core :: MIME, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: bugzilla, Assigned: mscott)
References
(Depends on 1 open bug)
Details
(Keywords: crash, topcrash, Whiteboard: [nsbeta1+])
Crash Data
Attachments
(4 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
I found this problem while testing my fix for bug 77053. If you don't crah the first time you view the message, try a
second time :-)
1) Open a compose message window
2) Attach the web page www.marketwatch.com (use the file/attach page), You need to use a build that have the fix
for bug 77254
3) Send the mesage to yourself
4) Receive the message
5) Click on it to see it
6) ==> CRASH in MimeStreamComverter because we are trying to process a null URL!!!
If you are not crashing, select another message and then select again the message.
Reporter | ||
Comment 2•24 years ago
|
||
I tried a build from 2001041212 and it works fine but the build from 2001041304
crash when viewing this page for the second time. It really looks like a
regression of mscott cache landing on 04/12 at 20:48. Reassign to mscott
Assignee: ducarroz → mscott
Status: ASSIGNED → NEW
Comment 4•24 years ago
|
||
marking nsbeta1+
Assignee | ||
Comment 5•24 years ago
|
||
This crash is very similar to one we used to have involving relative image urls.
In this case, we have a relative path to a style sheet. The style system is
ignoring the BASE URL tag we are emitting which points to
http://www.marketwatch.com and instead attempts to resolve the relative link for
the style sheet on the imap url used to display the message. Of course this
causes us to think we have a valid imap url which points off to bogus folders
(whatever the structure of the relative link was) and we get all confused and
end up crashing.
To fix this for images with relative links, we had to make sure the BASE tag was
being honored for URL resolution and that fixed the crash.
cc'ing Marc our resident style system expert... It looks like when we resolve
the relative sytle sheet urls, we aren't using the BASE tag our mime emitter
generates. Do you know where we should start poking to look at this?
I'll attach a stack crawl showing where in the code imap is getting told to
incorrectly resolve the relative link.
To see the HTML we are emitting, one can turn on a MIME log by setting your log
module to MIME:5.
I wonder if the style rules get generated before the BASE tag is being parsed?
Probably not...but I thought I'd mention it.
Assignee | ||
Comment 6•24 years ago
|
||
Here's the stack crawl showing how we get called to resolve a relative link,
bypassing the BASE tag....
nsMsgMailNewsUrl::Resolve(nsMsgMailNewsUrl * const 0x047403a4, const char *
0x0012dfb4, char * * 0x0012e0e4) line 516
NS_MakeAbsoluteURIWithCharset(char * * 0x0012e0e4, const nsString & {...},
nsIDocument * 0x04754058, nsIURI * 0x047403a4, nsIIOService * 0x00d11c60,
nsICharsetConverterManager * 0x00d2ad10) line 155 + 26 bytes
nsHTMLAnchorElement::GetHrefCString(nsHTMLAnchorElement * const 0x047c555c, char
* & 0x00000000) line 689 + 49 bytes
nsStyleUtil::IsHTMLLink(nsIContent * 0x047c5528, nsIAtom * 0x00d987f0,
nsIPresContext * 0x03ceb420, nsLinkState * 0x0012e188) line 519
SelectorMatchesData::SelectorMatchesData(nsIPresContext * 0x03ceb420, nsIContent
* 0x047c5528, nsISupportsArray * 0x047cf368, nsCompatibility * 0x00000000) line
2815 + 29 bytes
ContentEnumData::ContentEnumData(nsIPresContext * 0x03ceb420, nsIContent *
0x047c5528, nsISupportsArray * 0x047cf368) line 3272 + 29 bytes
CSSRuleProcessor::RulesMatching(CSSRuleProcessor * const 0x04734a50,
nsIPresContext * 0x03ceb420, nsIAtom * 0x00da4420, nsIContent * 0x047c5528,
nsIStyleContext * 0x04743e28, nsISupportsArray * 0x047cf368) line 3435
EnumRulesMatching(nsISupports * 0x04734a50, void * 0x0012e26c) line 841
nsSupportsArray::EnumerateForwards(nsSupportsArray * const 0x047346e8, int
(nsISupports *, void *)* 0x02299f20 EnumRulesMatching(nsISupports *, void *),
void * 0x0012e26c) line 357 + 20 bytes
StyleSetImpl::WalkRuleProcessors(int (nsISupports *, void *)* 0x02299f20
EnumRulesMatching(nsISupports *, void *), void * 0x0012e26c, nsIContent *
0x047c5528) line 2282
StyleSetImpl::ResolveStyleFor(nsIPresContext * 0x03ceb420, nsIContent *
0x047c5528, nsIStyleContext * 0x04743e28, int 0) line 943
nsPresContext::ResolveStyleContextFor(nsPresContext * const 0x03ceb420,
nsIContent * 0x047c5528, nsIStyleContext * 0x04743e28, int 0, nsIStyleContext *
* 0x0012e334) line 697 + 38 bytes
nsCSSFrameConstructor::ResolveStyleContext(nsIPresContext * 0x03ceb420, nsIFrame
* 0x04722750, nsIContent * 0x047c5528, nsIAtom * 0x00d987f0, nsIStyleContext * *
0x0012e334) line 6795 + 31 bytes
nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x04015c70, nsIPresContext
* 0x03ceb420, nsFrameConstructorState & {...}, nsIContent * 0x047c5528, nsIFrame
* 0x04722750, nsFrameItems & {...}) line 7150 + 53 bytes
nsCSSFrameConstructor::ProcessBlockChildren(nsIPresShell * 0x04015c70,
nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent *
0x047c4a90, nsIFrame * 0x04722750, int 1, nsFrameItems & {...}, int 1) line
12465 + 37 bytes
nsCSSFrameConstructor::ConstructBlock(nsIPresShell * 0x04015c70, nsIPresContext
* 0x03ceb420, nsFrameConstructorState & {...}, const nsStyleDisplay *
0x047cd8b4, nsIContent * 0x047c4a90, nsIFrame * 0x04722678, nsIStyleContext *
0x04743e28, nsIFrame * 0x04722750) line 12414 + 36 bytes
nsCSSFrameConstructor::ConstructFrameByDisplayType(nsIPresShell * 0x04015c70,
nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, const
nsStyleDisplay * 0x047cd8b4, nsIContent * 0x047c4a90, nsIFrame * 0x04722678,
nsIStyleContext * 0x04743e28, nsFrameItems & {...}) line 6511 + 43 bytes
nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x04015c70,
nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent *
0x047c4a90, nsIFrame * 0x04722678, nsIAtom * 0x00d9b5f8, int 3, nsIStyleContext
* 0x04743e28, nsFrameItems & {...}, int 0) line 7298 + 48 bytes
nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x04015c70, nsIPresContext
* 0x03ceb420, nsFrameConstructorState & {...}, nsIContent * 0x047c4a90, nsIFrame
* 0x04722678, nsFrameItems & {...}) line 7165 + 56 bytes
nsCSSFrameConstructor::ProcessBlockChildren(nsIPresShell * 0x04015c70,
nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent *
0x046ac118, nsIFrame * 0x04722678, int 1, nsFrameItems & {...}, int 1) line
12465 + 37 bytes
nsCSSFrameConstructor::ConstructBlock(nsIPresShell * 0x04015c70, nsIPresContext
* 0x03ceb420, nsFrameConstructorState & {...}, const nsStyleDisplay *
0x047cd57c, nsIContent * 0x046ac118, nsIFrame * 0x047225f0, nsIStyleContext *
0x04865f60, nsIFrame * 0x04722678) line 12414 + 36 bytes
nsCSSFrameConstructor::ConstructFrameByDisplayType(nsIPresShell * 0x04015c70,
nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, const
nsStyleDisplay * 0x047cd57c, nsIContent * 0x046ac118, nsIFrame * 0x047225f0,
nsIStyleContext * 0x04865f60, nsFrameItems & {...}) line 6511 + 43 bytes
nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x04015c70,
nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent *
0x046ac118, nsIFrame * 0x047225f0, nsIAtom * 0x00d994b0, int 3, nsIStyleContext
* 0x04865f60, nsFrameItems & {...}, int 0) line 7298 + 48 bytes
nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x04015c70, nsIPresContext
* 0x03ceb420, nsFrameConstructorState & {...}, nsIContent * 0x046ac118, nsIFrame
* 0x047225f0, nsFrameItems & {...}) line 7165 + 56 bytes
nsCSSFrameConstructor::ProcessChildren(nsIPresShell * 0x04015c70, nsIPresContext
* 0x03ceb420, nsFrameConstructorState & {...}, nsIContent * 0x047589f8, nsIFrame
* 0x047225f0, int 1, nsFrameItems & {...}, int 1, nsTableCreator * 0x00000000)
line 11307 + 43 bytes
nsCSSFrameConstructor::ConstructDocElementFrame(nsIPresShell * 0x04015c70,
nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent *
0x047589f8, nsIFrame * 0x047218ac, nsIStyleContext * 0x047a4db0, nsIFrame * &
0x047225f0) line 3549
nsCSSFrameConstructor::ReconstructDocElementHierarchy(nsCSSFrameConstructor *
const 0x0466d798, nsIPresContext * 0x03ceb420) line 7363 + 63 bytes
StyleSetImpl::ReconstructDocElementHierarchy(StyleSetImpl * const 0x046b7b18,
nsIPresContext * 0x03ceb420) line 1233
PresShell::ReconstructFrames() line 4899 + 38 bytes
PresShell::StyleSheetAdded(PresShell * const 0x04015c78, nsIDocument *
0x04754058, nsIStyleSheet * 0x047cc590) line 4911
nsDocument::InsertStyleSheetAt(nsDocument * const 0x04754058, nsIStyleSheet *
0x047cc590, int 1, int 1) line 1293
CSSLoaderImpl::InsertSheetInDoc(nsICSSStyleSheet * 0x047cc590, int 2, nsIContent
* 0x047cecb8, int 1, nsICSSLoaderObserver * 0x047584a4) line 1103
CSSLoaderImpl::SheetComplete(nsICSSStyleSheet * 0x047cc590, SheetLoadData *
0x047cef18) line 813
CSSLoaderImpl::ParseSheet(nsIUnicharInputStream * 0x047ceec0, SheetLoadData *
0x047cef18, int & 1, nsICSSStyleSheet * & 0x047cc590) line 868
CSSLoaderImpl::LoadInlineStyle(CSSLoaderImpl * const 0x04758620, nsIContent *
0x047cecb8, nsIUnicharInputStream * 0x047ceec0, const nsString & {...}, const
nsString & {...}, int -1, int 2, nsIParser * 0x047567a0, int & 1,
nsICSSLoaderObserver * 0x047584a4) line 1287 + 24 bytes
Assignee | ||
Comment 7•24 years ago
|
||
Comment 8•24 years ago
|
||
I checked this out and the base HREF is not the problem. I created a testcase
that uses the base HREF and links a stylesheet using the relative URL, it works
fine. The problem only happens when I follow the HTML in the MIME log and put
the HEAD inside of the BODY, then it is apparently ignored.
I'll attach first the working testcase, then the same testcase with the HEAD
inside of the BODY showing that it does not work. If we want to handle this kind
of markup we will probably have to get some work from the parser folks.
Comment 9•24 years ago
|
||
Comment 10•24 years ago
|
||
Comment 11•24 years ago
|
||
The structure of the markup shown in the MIME log is really bad. I remember
seeing thsi sort of problem before and IIRC we decided that libmime was not able
to make any better markup so we had to shelve the bug. I wish I could solve thsi
in style, but the BASE HREF is never even getting to the CSSLoader...
Assignee | ||
Comment 12•24 years ago
|
||
yes the html the mime generator (which dates back to netscape 2.0??) is pretty
nasty.
So if the BASE tag were somehow inside the HEAD tag instead of coming after the
HEAD tag, the style system will then start honoring the base tag?
I'll take a look to see if I can make mime do that. Although I think we've
looked at that before and it wasn't feasible at the time since we emit the head
tag before we even start converting the body........thanks Marc.
Assignee | ||
Comment 13•24 years ago
|
||
Marc, one of your comments confused me a bit. You said: "HEAD is enclosed by
BODY (as showin in the MIME trace) and is apparently ignored"
When I look at the mime log, i'm seeing the head tag, then the body tag and the
base is inside the body. I'm not seeing the head enclosed by the body. did I
misread what you wrote?
Comment 14•24 years ago
|
||
Oops - I was not clear. What I'm seeing is as follows:
The base HREF is in the first BODY, then another HTML and BODY are opened, then
another HEAD (after the BODY that follows the <!-- C-WRAP MODS --> comment), and
then the LINK is found. Here is some markup that tries to mimic what I see:
<html>
<body>
<BASE HREF="http://cbs.marketwatch.com/news/default.asp?siteid=mktw">
<html><body><head>
<link rel=stylesheet type="text/css" href="/styles/css/global.asp">
</head>
<p class="t23">test: class t23 has color=#ff0000
</body>
</html>
So, the HEAD is in the BODY, but that is just for the LINK. The BASE HREF is in
the first BODY. If I pull the BASE HREF out of the BODY and either put it into
the head OR just leave it hanging then it seems to apply. For example, this
modification of the previous markup works:
<BASE HREF="http://cbs.marketwatch.com/news/default.asp?siteid=mktw">
<html><body><head>
<link rel=stylesheet type="text/css" href="/styles/css/global.asp">
</head>
<p class="t23">test: class t23 has color=#ff0000
</body>
</html>
I hope that is less unclear, and possibly even helpful!
Comment 15•24 years ago
|
||
This is a topcrash for M09, added topcrash keyword
Added M09 crash [@ nsStreamConverter::Init ] to Summary for tracking.
Here is a recent stack trace:
nsStreamConverter::Init
[d:\builds\seamonkey\mozilla\mailnews\mime\src\nsStreamConverter.cpp line 550]
nsStreamConverter::AsyncConvertData
[d:\builds\seamonkey\mozilla\mailnews\mime\src\nsStreamConverter.cpp line 1075]
nsStreamConverterService::AsyncConvertData
[d:\builds\seamonkey\mozilla\netwerk\streamconv\src\nsStreamConverterService.cpp
line 639]
nsDocumentOpenInfo::RetargetOutput
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp line 444]
nsDocumentOpenInfo::DispatchContent
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp line 397]
nsDocumentOpenInfo::OnStartRequest
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp line 242]
nsStreamListenerTee::OnStartRequest
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerTee.cpp line 14]
nsOnStartRequestEvent0::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp line
212]
nsStreamListenerEvent0::HandlePLEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp line
107]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c
line 589]
PL_ProcessPendingEvents
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 522]
_md_EventReceiverProc
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 1070]
KERNEL32.DLL + 0x248f7 (0xbff848f7)
0x00688b5a
Here are some comments from recent crashes:
(29679498) Comments: crash when browsing
(29676687) Comments: Crash when loading a mail message with a linked page.
(29668792) Comments: select a message IMAP
(29668596) Comments: Opened message from search results (sent folder)
Keywords: topcrash
Summary: Crash when viewing a message with www.marketwatch.com attached → Crash when viewing a message with www.marketwatch.com attached; M09 crash [@ nsStreamConverter::Init ]
Assignee | ||
Comment 16•24 years ago
|
||
*** Bug 78731 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 17•24 years ago
|
||
*** Bug 78797 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 18•24 years ago
|
||
So this turns out to be a little harder than I thought it would be. =). First of
all a message could have multiple inline parts (i.e. I can send multiple web
pages in the same message). This means you could run into multiple BASE tags, 1
for each inlined part.
I thought I would make the bad HTML mime emits a little worse by wrapping each
inline part with it's own HTML & BODY tags. That way I could have the base tag
for that part stand outside of the BODY for that part. Something like this:
<html> // for the inline part
<BASE HREF="http://cbs.marketwatch.com/news/default.asp?siteid=mktw">
<body> // for the inline part
// now the RAW html for the web page which has it's own html, body and head tags...
<html>
<body>
<head>
<link rel=stylesheet type="text/css" href="/styles/css/global.asp">
</head>
</body>
</html>
// now close out our inlined part
</body>
</html>
Unfortunately that didn't have the effect I was hoping for. We still don't find
the BASE url when resoloving the link.
My knowledge of HTML isn't could enough to even know if my approach is valid or not.
Assignee | ||
Comment 19•23 years ago
|
||
does anyone know if there's an HTML tag you can use to enforce a "scoping"
policy with regards to the BASE tag?
i.e I really want to do something like:
<some tag>
<BASE ....>
<html><body> .... </body></html> // random raw html for the inlined web page
</some tag>
followed by the same wrapper around the next inline web page in the message:
<some tag>
<BASE ....>
<html><body> .... </body></html> // random raw html for the inlined web page
</some tag>
Comment 20•23 years ago
|
||
mscott, there is nothing I am aware of that does what you want. BASE is
technically limited to the HEAD, I think, so even supporting it in the body is a
quirkiness we have chosen to support (or support by accident). Given that, we
could always create a proprietary scoping tag...
I had another idea, in fact I think I've mentioned it before: why not make the
mail message wrap the individual 'inline' web pages in IFRAMEs? That way, they
would each be completly scoped. This way the markup could actually be valid too,
since I believe that we are taking advantage of some very quirky behaviors that
allow multiple heads, multiple html and body elements in the same document.
Just a thought...
Assignee | ||
Comment 21•23 years ago
|
||
that's a very interesting idea Marc. It certainly would clean up all the nested
html/head/body tags that we wrap around each inlined part in the message.
One problem that jumps out at me is that then each inline part scrolls
separately from the message body. Or is it possible to have several iframes
scroll together? I didn't think you could do that but maybe I'm wrong.
Comment 22•23 years ago
|
||
I think that each IFRAME would have to be the full size of the webpage so that
the IFRAME does not have its own scrollbar. I'm not sure how to do that part...
It might be possible to specify an automatic height on an IFRAME, but I couldn;t
figure it out. Maybe we could put some support into layout for automatic IFRAME
height to enable this. Width would just be 100% I think.
Reporter | ||
Comment 23•23 years ago
|
||
*** Bug 78988 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 24•23 years ago
|
||
I got a prototype of this working yesterday where I convert each inline HTML
part into an iframe with another imap url to fetch the part.
i.e.
<iframe scrolling="no" height="100%" width="100%" src="imap://.....&part=1.2>
I think this is an interesting avenue to take.
1) It cleans up some of the ugly HTML libmime generates because we no longer end
up nesting a bunch of html and body tags for each inline part.
2) It's going to make mstoltz happy from a security point of view. (More on that
later)
However the big draw back I see right now is that layout currentl does not allow
you to have multiple iframes scroll together. We have the intial iframe that has
the message body and a scroll bar. Inside of that iframe we now have iframes for
each inlined html part. We don't want vertical scrollbars for each of these
nested iframes. We want them to take up 100% and then rely on scrolling from the
parent frame.
My gut tells me this is going to be a hard requirement for the layout guys to
implement if we go down this path. But I don't want to speak for them =). Maybe
Marc wants to speak for them =).
Assignee | ||
Comment 25•23 years ago
|
||
*** Bug 74463 has been marked as a duplicate of this bug. ***
Comment 26•23 years ago
|
||
I'm not sure what it will take to make an iframe 'shrink-wrap' around the page
it contains - I'll start investigating and report back what I find.
Reporter | ||
Comment 27•23 years ago
|
||
*** Bug 80326 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 28•23 years ago
|
||
*** Bug 80326 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 29•23 years ago
|
||
*** Bug 79921 has been marked as a duplicate of this bug. ***
Comment 30•23 years ago
|
||
Note to qa contact, please test all the url's for the dup bugs when this is
fixed and being verified.
Comment 31•23 years ago
|
||
Marc, any luck?
Comment 32•23 years ago
|
||
No luck yet. To be honest, I've been swamped with other issues and have not put
a lot of effort into this. Is it critical? Shall we open a bug on me to put it
on my 0.9.1 radar?
Comment 33•23 years ago
|
||
My main concern is that there are already 8 dups of this which means it's not
too uncommon to get into this situation, and it's pretty bad to crash when
reading a message. If it's possible to come up with a solution for 0.9.1 it
would be appreciated.
Comment 34•23 years ago
|
||
I opened bug 80713 on the IFRAME height idea.
Reporter | ||
Comment 35•23 years ago
|
||
maybe I missed the point here but how comes it was working before? Do we really need to go the iFrame way or
should we just try to fix the regression?
Comment 36•23 years ago
|
||
Fixing the regression and improving the nasty markup from libmime are somewhat
orthogonal, I think. We can probably fix the crash, but I'm not sure we can
honor multiple misplaced <BASE> tags correctly...
Assignee | ||
Comment 37•23 years ago
|
||
*** Bug 80853 has been marked as a duplicate of this bug. ***
Comment 38•23 years ago
|
||
*** Bug 80759 has been marked as a duplicate of this bug. ***
Comment 39•23 years ago
|
||
I like JF's question: what's the simplest thing we can do to get the crash off
the radar right now? If we need a more elegant solution, we can file another
bug to cover that for m.9.2.
Assignee | ||
Comment 40•23 years ago
|
||
*** Bug 66402 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 41•23 years ago
|
||
Assignee | ||
Comment 42•23 years ago
|
||
Couple comments:
1) After spending the weekend and today hacking on mime to get this to work,
I've come to the conclusion that it just isn't possible. The best I could do was
get the base tag working some what iff the very first multi-mixed part in the
message contained the content-location header. Then and only then could I come
close to emitting the base tag as part of the first <header> tag we issue when
we begin to display a message. Otherwise, we always have to emit parts of the
message body we've already parsed (i.e. other parts) before we discover the
content location header in a subsequent part. I'm convinced that base tag urls
could not have worked under the current libmime architecture unless the parser
used to be able to discover the base tag when it was nested. The only way to
make this work would be to introduce another pass in libmime where we first
parse all the message parts scanning for a content-location header then begin
generating the html for the body and re-parsing the parts for display. Obviously
that's just not going to perform right.
I think the right idea is to go down the iframe for each part approach which is
a more long term solution.
2) So here's a hokey work around for .9.1. Don't allow resolution against
mailnews urls. We used to have this policy in place in NS6 but we took it out in
order to allow messages to use anchor tags (think status reports =)). This
patch, still allows anchors to get resolved against the mailnews url. So that
feature won't break. Everything else won't get resolved against mailnews urls
though.
One catch: this will cause something to break I just don't know what. I remember
writing in a bug a year or so ago "gee, you are really lucky I just enabled url
resolution for nsMsgMailNewsUrl to make anchors work. This is going to make this
bug work too...". I just don't know what bug that was.
Status: NEW → ASSIGNED
Can we not DOM-insert the <BASE HREF> tag when you see the Content-Base: or
Content-Location: header? I guess I don't understand why we need the multiple
passes, but it is clear to me that there are a _lot_ of things about MIME HTML
generation that I don't understand.
As far as having the <iframe>s scroll as a unit, I'm a little surprised that
it's not possible. Lots of sites have ads in <iframe>s, and they scroll with
the rest of the page, no?
Adding dbaron for possible CSS trickery.
Comment 44•23 years ago
|
||
> As far as having the <iframe>s scroll as a unit, I'm a little surprised that
> it's not possible. Lots of sites have ads in <iframe>s, and they scroll with
> the rest of the page, no?
I think what mscott meant was having the inner IFRAMEs shrink to the "intrinsic
height" of the document so that the inner IFRAMEs don't need scrollbars (but
only the outer ones do). While such rendering seems quite unnatural for IFRAMEs
it seems like the natural thing to do for OBJECTs containing text/html without
any specified height/width. However, that doesn't mean it wouldn't be hard to
implement. See
http://www.w3.org/TR/html4/struct/objects.html#embedded-documents
Assignee | ||
Comment 45•23 years ago
|
||
thanks for that link David. Yeah, something like the object tag is definetly
what we are looking for here.
Comment 46•23 years ago
|
||
FWIW, the RFE for implementing OBJECT for text/plain and text/html content has
been around for years and not much progress has been made, although there were
some recent suggestions of just making it work like an IFRAME. See bug 678.
Assignee | ||
Comment 47•23 years ago
|
||
Okay the work around has been checked in. I'm marking this bug fixed. QA:
there's a long list of bugs marked dups of this one that have different urls
which need tested. You'll have to back track through the links to find all the
urls that need tested. I just went through the first 5 or so and made sure they
all worked.
Remaining work for implementing an iframe or object tag for each inlined part
has been filed as a new Bug: 82280. Please cc yourself to that bug if you wish
track this further.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 48•23 years ago
|
||
FYI..I'm starting the verification on this now, it will take a little while to
get through all the links.
Comment 49•23 years ago
|
||
Using build 2001-05-23 on win, mac and linux I did a Send Page on all of the web
pages in all the duplicate bugs and this one to myself. I retrieved the msgs
and had no crashes. I will verify this. If we start seeing other pages crash
when viewing them in a mail message we should start a new bug and reference
this one for possible helpful information on testing for regression.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
Updated•13 years ago
|
Crash Signature: [@ nsStreamConverter::Init ]
You need to log in
before you can comment on or make changes to this bug.
Description
•