Acid2 and Acid3 tests in Thunderbird3 message pane?

2 views
Skip to first unread message

alta88[nntp]

unread,
May 19, 2008, 12:49:14 AM5/19/08
to

Here's something fun, and rather interesting. In Tb3, open up a
Console, copy/paste the entire single line javascript string below
(don't change or add line breaks) into the Evaluate textbox, and enter.
Make sure to set pref javascript.allow.mailnews = true. Try with both
Acid tests; change url1 to url2 in the loadURI..

var url1 = "http://acid3.acidtests.org";var url2 =
"http://www.webstandards.org/files/acid2/test.html#top";var threePane =
Components.classes['@mozilla.org/appshell/window-mediator;1'].getService(Components.interfaces.nsIWindowMediator).getMostRecentWindow("mail:3pane");gBrowser
=
threePane.document.getElementById("messagepane");gBrowser.loadURI(url1,
null, null);

JoeS

unread,
May 19, 2008, 6:04:58 PM5/19/08
to
alta88[nntp] wrote:

Here's something fun, and rather interesting.  In Tb3, open up a Console, copy/paste the entire single line javascript string below (don't change or add line breaks) into the Evaluate textbox, and enter.  Make sure to set pref javascript.allow.mailnews = true.  Try with both Acid tests; change url1 to url2 in the loadURI..

var url1 = "http://acid3.acidtests.org";var url2 = "http://www.webstandards.org/files/acid2/test.html#top";var threePane = Components.classes['@mozilla.org/appshell/window-mediator;1'].getService(Components.interfaces.nsIWindowMediator).getMostRecentWindow("mail:3pane");gBrowser = threePane.document.getElementById("messagepane");gBrowser.loadURI(url1, null, null);

I never thought of that way to execute the test. (Thanks) This method works for me, I get 68/100 on current trunk TB....JoeS

alta88

unread,
May 19, 2008, 8:38:41 PM5/19/08
to

well, it's even more interesting. i get a 70 for the embedded iframe
you sent, while only 68 via the loadURI method. since Fx3 (rc1) is 71,
that's encouraging (for us rich content types).

what is not so great is the pretty severe (apparent, not necessarily
empirical) failure of Acid2. wonder what it looks like in an iframe..
leading to the question of why content should be rendered/handled
differently in any way in the tb message pane than in the fx browser.

Ron K.

unread,
May 19, 2008, 8:51:13 PM5/19/08
to
alta88 keyboarded, On 5/19/2008 8:38 PM :

Tb 2.0.0.14 only got a 51 and 52 on Acid3 and was a disaster on Acid2
with a portion way over near the right margin. With Tb 3.0a2pre the
Acid2 had errors above the eyes, while Acid3 was around 68-70 on score.
At least Console correctly Warned on the blatantly bad CSS.

--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!

JoeS

unread,
May 19, 2008, 11:39:45 PM5/19/08
to
I actually was surprised that TB did as well as it did compared to the browser.
Core/layout can only work with what it is given. TB uses Mailnews:Mime to determine what should be rendered by layout.
Here are just a few of issues with styles and the Mime code:

https://bugzilla.mozilla.org/show_bug.cgi?id=154836

So, one of my "pet" issues, that is, "beating html composer/editor into submission", becomes irrelevent if the code is
ignored in rendering.

--
JoeS

Ron K.

unread,
May 19, 2008, 11:59:23 PM5/19/08
to
JoeS keyboarded, On 5/19/2008 11:39 PM :

Remember that Tb has the deck stacked against it with Acid3. The
failure point was network access, which could well have come from a CAPS
restriction.

Mark Banner

unread,
May 20, 2008, 8:51:49 AM5/20/08
to
alta88 wrote:
> what is not so great is the pretty severe (apparent, not necessarily
> empirical) failure of Acid2. wonder what it looks like in an iframe..
> leading to the question of why content should be rendered/handled
> differently in any way in the tb message pane than in the fx browser.

A bit of a guess, could it be that we don't build the mathml module? Its
related to markup, but I couldn't determine if it was related to Acid 2
in the brief 2 mins I spent searching on it.

Standard8

alta88[nntp]

unread,
May 20, 2008, 11:09:52 PM5/20/08
to

only related bug i found was https://bugzilla.mozilla.org/show_bug.cgi?id=255747.  or, as you say, it could be a simple matter of building with mathml or other mod found in fx.

there are a number of Tb content rendering bugs.  but rather than someone hunting this stuff down, it'd be so much easier to just fold Fx into the Tb message pane.   so many better messaging things to do rather than reinvent the wheel of rendering and content type handling so many others are working on.


Mark Banner

unread,
May 21, 2008, 3:17:51 AM5/21/08
to
alta88[nntp] wrote:
> there are a number of Tb content rendering bugs. but rather than
> someone hunting this stuff down, it'd be so much easier to just fold Fx
> into the Tb message pane. so many better messaging things to do rather
> than reinvent the wheel of rendering and content type handling so many
> others are working on.

Although not necessarily exactly the same, the message pane is already
"FF". The message pane uses a <browser> element (although with things
like history disabled) which is exactly the same element that Firefox
uses to display its web content.

We don't reinvent the wheel of rendering and content type handling, that
is why there is a core code base between the two apps. Obviously some of
it has to be special cased (due to the different functionality of the
two apps), but the core code is the same.

Standard8

alta88[nntp]

unread,
May 21, 2008, 8:42:05 AM5/21/08
to
yes, i know it's based on core code.  yet it's eliminating the apparent special cases that i'm talking about, of which there are not a just a few besides Acid2 or rendering.  another example is the bug about POST forms. and inline plugins, while better in Tb3 than before, are not yet there.  all these are solved in Fx.

i'd say build with the entire Fx, history included.  experimentation with sql as a store would be advanced, for one.  and then one wouldn't need Fx.  alternatively, one could build an executable that was Fx with all the Tb backend code, with folderpane in the sidebar and threadpane loading in a new xul pane..



Mark Banner

unread,
May 21, 2008, 10:49:00 AM5/21/08
to
alta88[nntp] wrote:
> i'd say build with the entire Fx, history included. experimentation
> with sql as a store would be advanced, for one. and then one wouldn't
> need Fx. alternatively, one could build an executable that was Fx with
> all the Tb backend code, with folderpane in the sidebar and threadpane
> loading in a new xul pane..

So build Fx with everything included? That really sounds like SeaMonkey
to me, just a slightly different style.

I think that most of our problems are not caused by us excluding bits of
Firefox from the build, but the fact we haven't handled the edge cases
properly.

FWIW you'll already find sqlite within Thunderbird, even though we don't
build history. There are already various bugs and we've already had
various discussions on moving to sql as a store, I think I can summarise
that the general opinion is that we'd like to move away from mork, but
there's a *lot* of intermediate rework before we can get to that stage.

Standard8

Eddy Nigg (StartCom Ltd.)

unread,
May 21, 2008, 1:52:30 PM5/21/08
to dev-apps-t...@lists.mozilla.org
Mark Banner:

> alta88[nntp] wrote:
>
>> i'd say build with the entire Fx, history included. experimentation
>> with sql as a store would be advanced, for one. and then one wouldn't
>> need Fx. alternatively, one could build an executable that was Fx with
>> all the Tb backend code, with folderpane in the sidebar and threadpane
>> loading in a new xul pane..
>>
>
> So build Fx with everything included? That really sounds like SeaMonkey
> to me, just a slightly different style.
>
>
I think we explored such an option already once. It was envision to
provide tabs with different functions, like mail, calendar and browser
(Firefox). Instead of having two windows on the desktop, just one. I
think this would be a different approach in relation to the UI compared
to SeaMonkey.


Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390

alta88[nntp]

unread,
May 21, 2008, 4:45:16 PM5/21/08
to



---On 2008.May.21 01:52 PM, Eddy Nigg (StartCom Ltd.) wrote:
Mark Banner:
alta88[nntp] wrote:
  
i'd say build with the entire Fx, history included.  experimentation
with sql as a store would be advanced, for one.  and then one wouldn't
need Fx.  alternatively, one could build an executable that was Fx with
all the Tb backend code, with folderpane in the sidebar and threadpane
loading in a new xul pane..
    

So build Fx with everything included? That really sounds like SeaMonkey
to me, just a slightly different style.

  
I think we explored such an option already once. It was envision to provide tabs with different functions, like mail, calendar and browser (Firefox). Instead of having two windows on the desktop, just one. I think this would be a different approach in relation to the UI compared to SeaMonkey.
i agree, what i described is a rather different UI integration approach than SM.  but instead of tabs (like Spicebird), i would prefer even tighter integration, such that Places/Library folders (Bookmarks, History) could be on an equivalent level as an IMAP account (etc) folder.  Library is (can be) basically 2 of the 3 Tb panes.  integrating messaging (folderpane + threadpane) there would create a sea change app, imo.

as to not including bits of Fx - i'd have to say those bits are the edge cases.  messaging shouldn't have to muck with the content portion at all, just hand it off.  i understand the history, etc, but think we can reverse that.

Eddy Nigg (StartCom Ltd.)

unread,
May 21, 2008, 4:58:34 PM5/21/08
to alta88[nntp], David Ascher, dev-apps-t...@lists.mozilla.org
alta88[nntp]:

>> I think we explored such an option already once. It was envision to
>> provide tabs with different functions, like mail, calendar and browser
>> (Firefox). Instead of having two windows on the desktop, just one. I
>> think this would be a different approach in relation to the UI
>> compared to SeaMonkey.
>>
> i agree, what i described is a rather different UI integration approach
> than SM. but instead of tabs (like Spicebird), i would prefer even
> tighter integration, such that Places/Library folders (Bookmarks,
> History) could be on an equivalent level as an IMAP account (etc)
> folder. Library is (can be) basically 2 of the 3 Tb panes. integrating
> messaging (folderpane + threadpane) there would create a sea change app,
> imo.
>
> as to not including bits of Fx - i'd have to say those bits are the edge
> cases. messaging shouldn't have to muck with the content portion at
> all, just hand it off. i understand the history, etc, but think we can
> reverse that.
>
>

I'm not sure what it entails and how significant such a change would be,
but this idea should be evaluated carefully and taken into
consideration. David?

alta88[nntp]

unread,
May 21, 2008, 6:23:03 PM5/21/08
to


---On 2008.May.21 04:58 PM, Eddy Nigg (StartCom Ltd.) wrote:
> alta88[nntp]:
>>> I think we explored such an option already once. It was envision to
>>> provide tabs with different functions, like mail, calendar and browser
>>> (Firefox). Instead of having two windows on the desktop, just one. I
>>> think this would be a different approach in relation to the UI
>>> compared to SeaMonkey.
>>>
>> i agree, what i described is a rather different UI integration approach
>> than SM. but instead of tabs (like Spicebird), i would prefer even
>> tighter integration, such that Places/Library folders (Bookmarks,
>> History) could be on an equivalent level as an IMAP account (etc)
>> folder. Library is (can be) basically 2 of the 3 Tb panes. integrating
>> messaging (folderpane + threadpane) there would create a sea change app,
>> imo.
>>
>> as to not including bits of Fx - i'd have to say those bits are the edge
>> cases. messaging shouldn't have to muck with the content portion at
>> all, just hand it off. i understand the history, etc, but think we can
>> reverse that.
>>
>>
>
> I'm not sure what it entails and how significant such a change would
> be, but this idea should be evaluated carefully and taken into
> consideration. David?
>

Let's see if we can't spec out a proof of concept at a high level:

1. Package Account Settings code; when creating an account, create the
Account Folder as a peer of History/Bookmarks in Library, create all the
files in $profile just as is currently done in a Tb profile.
2. Library #contentView already has a <deck>, so really easy to overlay
Tb's #threadPaneBox via xul and programatically switch. Of course, need
to keep Tb's fast custom threadpane tree code.
3. Package relevant protocol code. Set up initialize code/listeners etc.
4. Massage content into html - even Google can do it for gmail.. Load
into a Firefox tab.
5. Toolbars - Lightning did a nice job on their version of Customize.
6. Package ancillary code like AB, Compose, etc; not hard as they are
all separate windows.
7. Build it; or is there a remote chance an extension is enough.
Anyway, want to brand as Thunderbird.

Can you imagine how much cruft can be jettisoned this way? Now, there's
lots in the details maybe, but I think Tb needs a serious shot of "new
improved", and not in a follow Spicebird way.

JoeS

unread,
May 21, 2008, 8:04:28 PM5/21/08
to
Mark Banner wrote:
> alta88[nntp] wrote:
>> i'd say build with the entire Fx, history included. experimentation
>> with sql as a store would be advanced, for one. and then one wouldn't
>> need Fx. alternatively, one could build an executable that was Fx with
>> all the Tb backend code, with folderpane in the sidebar and threadpane
>> loading in a new xul pane..
>
> So build Fx with everything included? That really sounds like SeaMonkey
> to me, just a slightly different style.
>
> I think that most of our problems are not caused by us excluding bits of
> Firefox from the build, but the fact we haven't handled the edge cases
> properly.

As far as javascript and the DOM is concerned, Thunderbird was hobbled very early in it's history:
I understand the security concerns for Mail, but I think Newsgroups are a different story.
Note that they apply to both mail and news, and a very difficult to split with a custom CAPS policy.

// Restrictions on the DOM for mail/news - see bugs 66938 and 84545
pref("capability.policy.mailnews.sites", "mailbox: imap: news:");

pref("capability.policy.mailnews.*.attributes.get", "noAccess");
pref("capability.policy.mailnews.*.baseURI.get", "noAccess");
pref("capability.policy.mailnews.*.data.get", "noAccess");
pref("capability.policy.mailnews.*.getAttribute", "noAccess");
pref("capability.policy.mailnews.HTMLDivElement.getAttribute", "sameOrigin");
pref("capability.policy.mailnews.*.getAttributeNS", "noAccess");
pref("capability.policy.mailnews.*.getNamedItem", "noAccess");
pref("capability.policy.mailnews.*.getNamedItemNS", "noAccess");
pref("capability.policy.mailnews.*.host.get", "noAccess");
pref("capability.policy.mailnews.*.hostname.get", "noAccess");
pref("capability.policy.mailnews.*.href.get", "noAccess");
pref("capability.policy.mailnews.*.innerHTML.get", "noAccess");
pref("capability.policy.mailnews.*.lowSrc.get", "noAccess");
pref("capability.policy.mailnews.*.nodeValue.get", "noAccess");
pref("capability.policy.mailnews.*.pathname.get", "noAccess");
pref("capability.policy.mailnews.*.protocol.get", "noAccess");
pref("capability.policy.mailnews.*.src.get", "noAccess");
pref("capability.policy.mailnews.*.substringData.get", "noAccess");
pref("capability.policy.mailnews.*.text.get", "noAccess");
pref("capability.policy.mailnews.*.title.get", "noAccess");
pref("capability.policy.mailnews.DOMException.toString", "noAccess");
pref("capability.policy.mailnews.HTMLAnchorElement.toString", "noAccess");
pref("capability.policy.mailnews.HTMLDocument.domain", "noAccess");
pref("capability.policy.mailnews.HTMLDocument.URL", "noAccess");
pref("capability.policy.mailnews.Location.toString", "noAccess");
pref("capability.policy.mailnews.Range.toString", "noAccess");
pref("capability.policy.mailnews.Window.blur", "noAccess");
pref("capability.policy.mailnews.Window.focus", "noAccess");
pref("capability.policy.mailnews.Window.innerWidth.set", "noAccess");
pref("capability.policy.mailnews.Window.innerHeight.set", "noAccess");
pref("capability.policy.mailnews.Window.moveBy", "noAccess");
pref("capability.policy.mailnews.Window.moveTo", "noAccess");
pref("capability.policy.mailnews.Window.name.set", "noAccess");
pref("capability.policy.mailnews.Window.outerHeight.set", "noAccess");
pref("capability.policy.mailnews.Window.outerWidth.set", "noAccess");
pref("capability.policy.mailnews.Window.resizeBy", "noAccess");
pref("capability.policy.mailnews.Window.resizeTo", "noAccess");
pref("capability.policy.mailnews.Window.screenX.set", "noAccess");
pref("capability.policy.mailnews.Window.screenY.set", "noAccess");
pref("capability.policy.mailnews.Window.sizeToContent", "noAccess");
pref("capability.policy.mailnews.document.load", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.channel", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.getInterface", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.responseXML", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.responseText", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.status", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.statusText", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.abort", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.getAllResponseHeaders", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.getResponseHeader", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.open", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.send", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.setRequestHeader", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.readyState", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.overrideMimeType", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.onload", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.onerror", "noAccess");
pref("capability.policy.mailnews.XMLHttpRequest.onreadystatechange", "noAccess");
pref("capability.policy.mailnews.XMLSerializer.serializeToString", "noAccess");
pref("capability.policy.mailnews.XMLSerializer.serializeToStream", "noAccess");
pref("capability.policy.mailnews.DOMParser.parseFromString", "noAccess");
pref("capability.policy.mailnews.DOMParser.parseFromStream", "noAccess");
pref("capability.policy.mailnews.SOAPCall.transportURI", "noAccess");
pref("capability.policy.mailnews.SOAPCall.verifySourceHeader", "noAccess");
pref("capability.policy.mailnews.SOAPCall.invoke", "noAccess");
pref("capability.policy.mailnews.SOAPCall.asyncInvoke", "noAccess");
pref("capability.policy.mailnews.SOAPResponse.fault", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.styleURI", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.getAssociatedEncoding", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.setEncoder", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.getEncoder", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.setDecoder", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.setDecoder", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.getDecoder", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.defaultEncoder", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.defaultDecoder", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.schemaCollection", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.encode", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.decode", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.mapSchemaURI", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.unmapSchemaURI", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.getInternalSchemaURI", "noAccess");
pref("capability.policy.mailnews.SOAPEncoding.getExternalSchemaURI", "noAccess");
pref("capability.policy.mailnews.SOAPFault.element", "noAccess");
pref("capability.policy.mailnews.SOAPFault.faultNamespaceURI", "noAccess");
pref("capability.policy.mailnews.SOAPFault.faultCode", "noAccess");
pref("capability.policy.mailnews.SOAPFault.faultString", "noAccess");
pref("capability.policy.mailnews.SOAPFault.faultActor", "noAccess");
pref("capability.policy.mailnews.SOAPFault.detail", "noAccess");
pref("capability.policy.mailnews.SOAPHeaderBlock.actorURI", "noAccess");
pref("capability.policy.mailnews.SOAPHeaderBlock.mustUnderstand", "noAccess");
pref("capability.policy.mailnews.SOAPParameter", "noAccess");
pref("capability.policy.mailnews.SOAPPropertyBagMutator.propertyBag", "noAccess");
pref("capability.policy.mailnews.SOAPPropertyBagMutator.addProperty", "noAccess");
pref("capability.policy.mailnews.SchemaLoader.load", "noAccess");
pref("capability.policy.mailnews.SchemaLoader.loadAsync", "noAccess");
pref("capability.policy.mailnews.SchemaLoader.processSchemaElement", "noAccess");
pref("capability.policy.mailnews.SchemaLoader.onLoad", "noAccess");
pref("capability.policy.mailnews.SchemaLoader.onError", "noAccess");
pref("capability.policy.mailnews.WSDLLoader.load", "noAccess");
pref("capability.policy.mailnews.WSDLLoader.loadAsync", "noAccess");
pref("capability.policy.mailnews.WSDLLoader.onLoad", "noAccess");
pref("capability.policy.mailnews.WSDLLoader.onError", "noAccess");
pref("capability.policy.mailnews.WebServiceProxyFactory.createProxy", "noAccess");
pref("capability.policy.mailnews.WebServiceProxyFactory.createProxyAsync", "noAccess");
pref("capability.policy.mailnews.WebServiceProxyFactory.onLoad", "noAccess");
pref("capability.policy.mailnews.WebServiceProxyFactory.onError", "noAccess");

Most of these capabilities would be allowed in Firefox rendering.

In addition to that, the OJI (Java) interface has been completely removed, and Plugins work but only on a
selected few with carefully controlled sources.

>
> Standard8

JoeS

unread,
May 21, 2008, 8:16:13 PM5/21/08
to

I'm pretty sure that Firefox no longer contains the NNTP protocol handler.
To test, paste this into the URL bar in Firefox:
news://news.mozilla.org:119/deidnZkHOOYYZKzVnZ2dnUVZ_hOdnZ2d%40mozilla.org?group=mozilla.dev.apps.thunderbird&key=3669

For me , it calls up Thunderbird, In Seamonkey, however, the message is loaded, and displays in a browser window.

I certainly would like to see full Firefox capabilities on a message, but would be satisfied if the content of a
viewed message could be passed to the browser. Shouldn't be too hard to do that in a similar manner to stand-alone
NVU I believe you can preview content with your default browser.(I haven't used that for a while, so I should check)

--
JoeS

alta88[nntp]

unread,
May 22, 2008, 8:27:07 AM5/22/08
to
i find being forced to open another window/app to look at content delivered in Tb to be a jarring and totally unnecessary interruption in workflow.  but, it's a user pref item and both methods should be supported.

what i would like is to read an email with a link, click the link and go to it in the same pane, click on another email and have it open in the same pane, and be able to back/forward through this history.

fixing the nntp handler would be an implementation detail in a combined fx/tb.

alta88[nntp]

unread,
May 22, 2008, 11:48:24 AM5/22/08
to


---On 2008.May.21 08:04 PM, JoeS wrote:
>
> As far as javascript and the DOM is concerned, Thunderbird was hobbled
> very early in it's history:
> I understand the security concerns for Mail, but I think Newsgroups
> are a different story.
> Note that they apply to both mail and news, and a very difficult to
> split with a custom CAPS policy.
>
> // Restrictions on the DOM for mail/news - see bugs 66938 and 84545
> pref("capability.policy.mailnews.sites", "mailbox: imap: news:");
>
> pref("capability.policy.mailnews.*.attributes.get", "noAccess");
> pref("capability.policy.mailnews.*.baseURI.get", "noAccess");

...


>
>
> Most of these capabilities would be allowed in Firefox rendering.
>
> In addition to that, the OJI (Java) interface has been completely
> removed, and Plugins work but only on a
> selected few with carefully controlled sources.
>
>

this is the sort of cruft i mean, among others. don't misunderstand,
i'm not trivializing security at all. but let's look at the
implementation correctness. first, these policies should only apply to
pop/imap servertype, as you say. second, reasons often given (in the
bugs) for removing javascript are popups - these are handled pretty well
by Fx natively, and other mechanisms via extension. for non pop/imap,
are we somehow unsatisfied with Fx security handling of content?

so the cases come down to scripts within pop/imap with access to content
document (not chrome) DOM. and the exploit(s) seem to be of the type
1)web bugs 2)reply/forward and included scripts having access to message
body or DOM revelatory information like mailbox:// uri etc. these of
course are legit - question is are they implemented in too blanket a
manner creating loss of functionality for rich content. one proposal in
66938 was to remove js tags from any fwd/reply. or, brainstorming here,
open inline content, in place, in another instance of <browser> that
would be passed a stream and thus not contain any interesting DOM info.

if rich content can be viewed in webmail without hassle and without
security issue, well that's where people will go.

Reply all
Reply to author
Forward
0 new messages