On Wed, Nov 28, 2012 at 4:26 PM, Ian Hickson i...@hixie.ch wrote:
All of this has already been discussed on this mailing list, so this is
not new information. I would please refer you to the earlier messages on
this topic. In general, unless there is substantial new information,
please don't
I can confirm this does not work on Android 4.2 where Chrome is the default
browser. In fact, it does not work on Chrome 23 desktop either.
Adam, should I fill a bug report on https://bugs.webkit.org/ or
http://code.google.com/p/android/issues/list ? I believe this is a Webkit
problem.
Thanks
Dear Ian,
Thank you opening a discussion about these interactive elements. It would be
disappointing to see these abandoned, for those who would like to see more
interactive non-javascript content.
I would note that CSS alone is able to implement styled menus but only for
'hover to activate'
Hi,
while working on https://bugzilla.mozilla.org/show_bug.cgi?id=785310 (block
setting
window.top.location from a document sandboxed without 'allow-top-navigation')
and discussing
the correct behavior with Bobby Holley, I found some interesting differences
between what Chrome and IE have
Greetings,
I'm not a browser implementor, but I have been dealing quite a bit with
menus and other GUI stuff from the web development perspective; so here it
goes some comments I hope implementors might find interesting:
I have put a first example on http://std.dragon-tech.org/mainmenu.png
All
On Tue, Nov 27, 2012 at 4:12 PM, Ian Hickson i...@hixie.ch wrote:
To move forward on this, here are some proposals:
#1: Drop menu and all related features. I don't think we should do this,
but if we can't get agreement on what to implement, this is the only
option left, so it's on the table.
There is a hack that allows css to handle clicks using hidden checkboxes and
adjacent :checked siblings. Its not terribly suited for menu-type behavior
though.
Fred Andrews freda...@live.com wrote:
Dear Ian,
Thank you opening a discussion about these interactive elements. It
would be
On Thu, 1 Mar 2012, Robert Kieffer wrote:
For reasons documented in
https://bugzilla.mozilla.org/show_bug.cgi?id=696301, I�d like to propose
that support for the �crossorigin� attribute be added to SCRIPT tags.
tl;dr - When applied to window.onerror information, the same-origin
policy
On Mon, 9 Apr 2012, Boris Zbarsky wrote:
On 4/9/12 2:16 PM, Gavin Peters (蓋文彼德斯) wrote:
However, this is strikingly similar to two other cases: when alink
rel=stylesheet ... element is removed from the document, in WebKit, we
remove the stylesheet from the document, although this isn't
On Tue, 8 May 2012, James Greene wrote:
The problem [with window.onerror is] that this mechanism does not allow
us to inspect the pertinent Error object at all: it only provides us
with three arguments at invocation time: message (string), fileName
(string), and lineNumber (number). These
On 11/28/12 7:42 PM, Ian Hickson wrote:
Done, at least on the HTML side. For now it just makes .sheet return null
for cross-origin resources.
Pretty sure that's not web-compatible...
If that's not quite right, please update this
bug with the details:
On 11/28/12 11:03 PM, Boris Zbarsky wrote:
Inheriting the mode isn't so bad, all it really does is decide whether or
not to send an Origin header.
Not quite. It also affects what happens when the server doesn't respond
with an appropriate Allow-Origin.
Oh, I see. You've added this taint
Ian,
The cost of parsing the script can be done async, even off the main thread
in theory, so it's a non-issue.
You have asserted many times that parsing is off the main thread, therefore it
doesn't matter. That makes the giant (and I think faulty) assumption that the
device in question has
Ian,
The only cost there could be is the cost
of executing the script, and it's already trivial to offload that: just
put all the code in a function, then call the function when you're ready.
It's already possible now to design scripts such that they don't run until
you call them, so you
Based on my reading of the source code, it seems that Gecko treats a
resource served as 'application/octet-stream' as an unknown type which
is sniffed as if no Content-Type was specified.
Are there security implications with doing this? Or should I add
'application/octet-stream' to the list of
There are substantial negative security consequences to sniffing
content on MIME types that are commonly used as default fallback
values by web servers or web application developers. This includes
text/plain and application/octet-stream.
/mz
On 11/29/12 1:30 AM, Gordon P. Hemsley wrote:
Based on my reading of the source code, it seems that Gecko treats a
resource served as 'application/octet-stream' as an unknown type which
is sniffed as if no Content-Type was specified.
Only for media (video and audio) loads. Note that the HTML
On Thu, Nov 29, 2012 at 1:30 AM, Gordon P. Hemsley gphems...@gmail.com wrote:
Based on my reading of the source code, it seems that Gecko treats a
resource served as 'application/octet-stream' as an unknown type which
is sniffed as if no Content-Type was specified.
Oh, wait, I forgot what I
On 11/29/12 2:07 AM, Gordon P. Hemsley wrote:
So perhaps a more useful question would be what to do in situations
like that—should mimesniff treat application/octet-stream as a type
supported by the browser for the purposes of sniffing images, audio
or video, fonts, or other media types?
The
19 matches
Mail list logo
