Adam Langley wrote:
From my reading of the spec, it appears that MathML embedded in HTML
documents (not just XHTML) is intended to work?
(http://www.whatwg.org/specs/web-apps/current-work/#mathml)
I.e. something like the following snippet should render as math?
body
math
msup
Ian Hickson wrote:
HTML5 requires that there not be a reload. Setting location.hash
eventually (if you follow the admittedly convoluted definitions) is
equivalent to running the navigation algorithm:
http://www.whatwg.org/specs/web-apps/current-work/#navigate
...which, in step 4, just
Kartikaya Gupta wrote:
Opera and Chrome will alert c1somegt;stuff/c1morestuff (escaping the angle bracket
inside the child element) and Firefox just outputs morestuff (presumably a bug).
It's actually rather purposeful, at least in terms of the code. It'd be
pretty easy to change to
Ian Hickson wrote:
For another example, consider an algorithm that wants to reduce the size of
the image by 1px horizontally (e.g. content-aware image resizing as demoed
using canvas at
http://labs.pimsworld.org/wp-content/uploads/2009/04/demo-content-aware-image-resizing-2/).
If we're shrinking
Ian Hickson wrote:
I don't see why the imagedata API isn't suitable for that. It's not like
if you're painting that on the canvas you'll want to leave the last row or
column unaffected. You'll want to clear it or some such, in practice.
I believe in this case the page actually wants to create
Simon Pieters wrote:
It's actually rather purposeful, at least in terms of the code. It'd
be pretty easy to change to returning the textContent instead (so
walking into kids).
textContent wouldn't emit the tags.
Yes, true. I thought that's what you were asking for...
I think the spec
Philip Jägenstedt wrote:
It would have to be part of the resource selection algorithm. Since that
waits for new source elements indefinitely, when exactly would you
decide to switch to fallback content? Bad solutions include
special-casing static markup and/or (falsely) assuming that scripts
Ian just pointed out to me that his current draft requires
HTMLCollections to implement a tags() method (which seems to do a filter
by tagName on the contents of the collection).
As far as I can tell, IE, Webkit, and Opera implement this; Gecko does
not. I was wondering whether any of the
Philip Jägenstedt wrote:
Anything that can cause the element to switch back and forth between
displaying fallback and video is a no-go, that would cause a race
condition for if plugins/images in the fallback content. If they have
event handlers the results will get ugly fast:
video
!--
Maciej Stachowiak wrote:
Support for HTMLCollection.tags() in WebKit predates the fork from
KHTML. So we don't know why it was originally added.
I guess the other question is whether you feel it's worth keeping...
-Boris
Masataka Yakura wrote:
I'm confused by this - what exact FF build did you test in? When I
try it in the current public 3.5, I get legend autowrapping itself
in a fieldset.
Tab Atkins Jr. wrote:
On the note of legend styling, currently a legend-in-fieldset isn't
handled by the standard CSS renderer *at all* in FF, last I heard
More precisely it's handled as having a special position value that
you can't override, more or less, and that position value forces
Ian Hickson wrote:
Actually what's going on is more subtle than that. When you set innerHTML,
it's actually triggering the deferred scripts right there, if it has them
loaded (e.g. inline scripts or cached scripts). If it doesn't have them
loaded yet, it drops them on the floor and doesn't
Ian Hickson wrote:
The change I have checked in makes us more compatible with what IE
actually does here, which pages are apparently relying on. We could also
make the spec introduce a whole new kind of behaviour, such as the one
Jonas described, but that seems just as likely to have
Ian Hickson wrote:
It's not clear to me that what you're proposing is any simpler than what
Jonas is proposing.
I agree it's no simpler; I'm saying it's more compatible with IE.
And I'm saying it's incompatible with IE in precisely the way that's
unacceptable to me as an implementor, I
Julian Reschke wrote:
For those who don't know it already...: http://codedread.com/fxpointer/.
For the record, Gecko has native support for XPointer anchors if you're
linking to an XML document. There's no infrastructure for evaluating
XPointer against HTML, though. That could probably
Anne van Kesteren wrote:
From what I heard so far it is there because of document.all. If document.all
does indeed need to return a separate object as HTML5 suggests we can probably
remove it from HTMLCollection in due course.
Given that the namedItem behavior of document.all is different
Anne van Kesteren wrote:
They are indeed distinct, but do share the same interface name in Opera the
moment, as far as I can tell...
Oh, the _name_ is shared in Gecko too. Just not anything else. ;)
In any case, my point was that we'd be ok with removing the tags member from
Michael Davidson wrote:
- As for persistence beyond browser lifetime, I understand the
reticence. However, similar problems have been solved in the past.
Flash asks the user for access to hardware like cameras. Surely being
able to take pictures of users is as scary as running code after the
Michael Davidson wrote:
I didn't realize this. So you think that everything on
addons.mozilla.org is vetted enough to not include malware?
We try... Note that given the extension model you don't have to put a
binary blob in the extension either, since extensions can make HTTP
requests and
Gregg Tavares wrote:
If it's so clear, why do you think 2 of the 4 browsers that implemented
it apparently got it wrong?
Because the implementations preceded the current spec text; they were
just implementing something like Apple's Canvas without trying too
hard to be compatible in edge
Maciej Stachowiak wrote:
I'm not sure if I'd be totally comfortable with putting something as
streamlined as the Firefox extensions model. As presented on
http://addons.mozilla.org/, it seems fine - the extensions posted
there are centrally vetted and reviewed, the user has to take a clear
Ian Hickson wrote:
I've changed the spec to do external deferred src=ed scripts at the end
of document load (blowing away the document as before), and inline
deferred scripts as soon as innerHTML is set, if it is set, or else along
with other deferred scripts at the end of document load.
Andrew Oakley wrote:
Most notably HTML5 says that the Content-Type header is used in
preference to the type attribute, whereas the browsers seem to honour
the attribute in preference to the header.
Firefox hasn't done that (at least across the board) since Firefox 3.0
shipped.
Note that the
Chris McCormick wrote:
Of course, the ECMA script is probably going to be too slow in the short term,
so moving forward it would be great if there was a library/API which can do the
following vector operations in the background at a speed faster than doing them
directly, element by element
Chris McCormick wrote:
It's a bit of an open ended how-long-is-a-piece-of-string sort of a question in
that you will generally make synthesizers which require less CPU than what your
computer is able to provide, for the obvious reason that they won't work
otherwise. So the real answer is that
Jeremy Orlow wrote:
and, when passed value is undefined (e.g. `setItem(key)`), which
behavior will be correct?
...
I believe this is the correct section of the spec to be looking
at: http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString
If so, I think it's pretty clear that
Ian Hickson wrote:
On Sun, 2 Sep 2007, Gavin Sharp wrote:
It appears this behavior was explicitly chosen in Mozilla, in bug 190561
(https://bugzilla.mozilla.org/show_bug.cgi?id=190561). I think the
arguments given in that bug might merit reconsideration; detection of
image existence is
Gavin Sharp wrote:
I don't actually recall what I was referring to in that message, but
observing the images affect on layout seems to work pretty well:
https://people.mozilla.com/~gavin/detect-image.html
A site that cared about that could send image types for its image 404s,
no? Or does
Philip Jägenstedt wrote:
In any event, judging by existing implementations, the behavior of
createImageData(w, h) isn't as clear as it needs to be:
Firefox:
Just to be clear, the Firefox code for this predates the spec text.
I would assume so does Webkit's.
Once we're actually trying
Ian Hickson wrote:
On Tue, 25 Aug 2009, Andrew Oakley wrote:
So if we had a type attribute of application/x-shockwave-flash, and a
Content-Type header of image/png we would use the flash plugin.
Following the HTML5 spec we would use the image renderer.
Ah, yes, that's intentional (doing
Jens Alfke wrote:
Local storage is a significant change from the browser's current data
model, and I think that (no offense) browser developers are not used to
taking care of user-critical data for longer than the duration of a DOM
tree or POST request. It's a change in perspective. Coming as
Philip Jägenstedt wrote:
I wasn't involved then, but I can only presume that there was no
perceived benefit of high-DPI ImageData since you can get high-quality
rendering just as well with techniques that don't rely on the canvas
being higher resolution than the display device.
To be clear,
Marius Gundersen wrote:
I've been playing around with the canvas element, making a 3D engine. It
works, but is incredibly slow. Part of the reason is probably that the
browser renders the canvas everytime I draw something to it.
Depends on what I mean by renders. Anything you draw to the
Ian Hickson wrote:
On Sun, 6 Sep 2009, Boris Zbarsky wrote:
Ian Hickson wrote:
1. Its element must be attached to the document.
I'm told this is considered a bug.
Told by whom, if I might ask?
I thought by you, but apparently I misunderstood the point you had been
making! I've changed
Michael A. Puls II wrote:
I'm trying to remember. Did you also say that FF makes some use of
display: none for fallback content
It does not, but it does make use of lack of CSS boxes...
and that if FF was fixed so
display:none didn't affect plug-in instantiation, both plug-ins in the
Ian Hickson wrote:
Since the whole point of text/plain sniffing is a workaround around a
known issue where content is reliably mis-marked as text/plain, and
since in this case there is a source of MIME information that's more
reliable than that, it's not clear to me why we want to continue
On 9/18/09 4:57 AM, Michael A. Puls II wrote:
We (Gecko) consider it a bug that a display:none object in a
document doesn't instantiate the plug-in.
BTW, what is the reason for considering it a bug?
Because the current behavior of having the plug-in instantiation handled
by effectively the
On 9/18/09 10:21 AM, Michael A. Puls II wrote:
Attaching a test.
Thanks for doing that!
In Opera:
If you switch the display to none, it destroys the plug-in instance.
Setting the display to something else again doesn't restore the previous
plug-in instance. It creates a new one that starts
On 9/18/09 6:35 PM, Michael A. Puls II wrote:
With object style=display: none data=file.swf?vid=file.flv when
the page is parsed (or added to the document), what would happen?
Would it be something like this?:
1. Create the plug-in instance.
2. fetch file.swf
3. Give the file.swf stream to
On 9/20/09 3:54 PM, Michael A. Puls II wrote:
O.K., so put simply, HTML5 should explicitly mention that the css
display property for object, embed (and applet in the handling
section) has absolutely no effect on plug-in instantiation and
destroying and has absolutely no effect on @src and @data
Section 2.6, item 3 says [1]:
When fetching resources for an element
The element's Document.
Is that supposed to be the element's ownerDocument? Or something else?
The term seems to be underdefined.
It's also not defined whether the document is to be examined at the
moment when
On 9/21/09 2:01 PM, Michael A. Puls II wrote:
I think Opera even defers
the fetching of display: none images until the display is changed.
With those, I believe, it does a synchronous GET when someone asks about
things about the image that need the image data, no?
I have no problem with a
On 9/26/09 4:11 PM, Joseph Pecoraro wrote:
I was aware of the potential for a thread to sit inside a batchUpdate. I
guess the basic idea would have been that batchUpdate would be a hint to
the UA.
So a stronger hint than the script is still running?
I don't think of this as overriding any
On 10/5/09 12:48 PM, Mark Kaplun wrote:
I have only learned now that there is a text/palin option that I have
never heard of, so maybe I'm wrong, but my impression is that there are
only two forms of form, a textual and a file upload. IMHO the browser
can inspect the form before submitting it
On 10/5/09 9:01 PM, Ian Hickson wrote:
Any suggestions? What do browsers actually do, white-box wise?
Gecko forbids most navigation between firing unload and the newly
loading page becoming the current page. most means all history
navigation (including reload()) and attempts to navigate via
On 10/5/09 9:35 PM, Ian Hickson wrote:
My testing showed browsers also stopped things like navigation triggered
by submitting a form to another frame (form target=).
Oh, right. The Gecko implementation of form submission and link clicks
performs the are we after unload firing started, and if
On 10/7/09 7:12 PM, Kartikaya Gupta wrote:
If a document is served as text/html, but contains an XML prolog with an
encoding attribute, it seems that all Firefox, Opera, and Chrome all pick up
the encoding from the prolog and use it when parsing the rest of the document.
(IE6 does not). The
On 10/7/09 7:51 PM, Kartikaya Gupta wrote:
I tried it again in Chrome and if I paste the above in the address bar I get
US-ASCII. But if I save it to a file and then load it I get UTF-8. I checked
the headers being sent from Apache and they don't include any sneaky encoding
hints, just
On 10/7/09 9:29 PM, Kartikaya Gupta wrote:
Using document.inputEncoding:
http://stakface.com/pub/mango/fakexml.html
http://stakface.com/pub/mango/fakexml_iso.html
Using a degree symbol in UTF-8:
http://stakface.com/pub/mango/fakexml2.html
http://stakface.com/pub/mango/fakexml2_iso.html
All of
On 10/7/09 9:52 PM, Kartikaya Gupta wrote:
Anything else that might be affecting this?
In general, yes. Charset info can come from the HTTP cache, from user
bookmarks, etc, etc.
In this case, though, it's totally my fault: I just forgot that I had
the HTML5 parser turned on locally.
On 10/8/09 12:26 AM, Kartikaya Gupta wrote:
So then is this behavior getting axed or specced?
Good question. It might just be that it's needed for compat with sites
sending XHTML as text/html :(
-Boris
On 10/9/09 12:04 PM, Aryeh Gregor wrote:
I don't know why back and forward don't work in the browsers I tried
it in
Here's what copy link location gives me for a randomly picked link in
the menu on the left in Firefox:
On 10/9/09 2:19 PM, Aryeh Gregor wrote:
I don't see how iframes would allow you to deliberately mess up
navigation in the same way as frames do.
I don't see how they wouldn't. Everything you can accomplish with
frameset and frame you can do with iframe plus gobs of javascript
to make the
On 10/9/09 2:55 PM, Peter Brawley wrote:
Framesets are part of the current HTML standard and should remain.
This isn't really a convincing argument. There are various other things
that are part of HTML 4.01 that are worth removing and have been removed.
That said, I'm not sure why there's
On 10/11/09 6:59 AM, Mark Kaplun wrote:
I think that in practice no one is writing his own mime handling
routines to handle the data in a post message, and people just use a
framework which handles it for them.
While this may be true (and I'm not sure it's as true as one would like)
some of
On 10/11/09 9:04 PM, Ian Hickson wrote:
http://www.hixie.ch/tests/adhoc/html/navigation/unload/cross-origin/004.html
I couldn't work out what Gecko is doing with it.
I'm not sure what's unclear. The click starts the load of
http://another.domain.libpr0n.com/pass and then the
On 10/11/09 11:06 AM, Mark Kaplun wrote:
Boris, I have agreed with your first response that I don't know enough
about all the crazy things that people might be doing, to make this
attribute to disappear. However I don't see how changing the default
mime type will have any affect on the existing
On 10/12/09 11:32 AM, Mark Kaplun wrote:
Is there any reason why someone will do such a thing by design? unless
there is some exotic reason, this is an example to a form which do not
perform its role.
That depends on whether the server actually expects to get anything from
the file input.
On 10/12/09 1:55 AM, Ian Hickson wrote:
Why is the form.submit() ignored? It's not ignored in, e.g.:
http://www.hixie.ch/tests/adhoc/html/navigation/unload/same-origin/004.html
But in this case the form action is same-origin with the load that's
happening
Oops, that's a vestigial
On 10/13/09 7:00 AM, Ian Hickson wrote:
http://www.hixie.ch/tests/adhoc/html/navigation/unload/same-origin/004.html
But in this case the form action is same-origin with the load that's
happening
As it is on the other one:
On 10/13/09 10:58 PM, Ian Hickson wrote:
Ah, I see. Yes, that makes sense. Are you ok with what the spec says
despite this minor difference? (It seems that what the spec says is a mote
more self-consistent, but I could be biased! ;-) )
Can you point me to the relevant spec text?
And note that
On 10/15/09 3:35 PM, Gregg Tavares wrote:
I was wondering if there as been a proposal for either an optional
argument to setInterval that makes it only callback if the window is
visible OR maybe a window.setRenderInterval.
You might be interested in
On 10/15/09 4:14 PM, Jeremy Orlow wrote:
I'd imagine that UAs could use an overly conservative metric of when
things are visible to make things cheaper if/when this is a concern.
It's a concern any time someone's checking it every 10ms interval
invocation. For example, I'm right now looking
On 10/16/09 4:12 PM, Ben Laurie wrote:
I realise this is only one of dozens of ways that HTML is unfriendly
to security, but, well, this seems like a bad idea - if the page
thinks it is embedding, say, some flash, it seems like a pretty bad
idea to allow the (possibly untrusted) site providing
On 10/16/09 8:21 PM, Ben Laurie wrote:
The point is that if I think I'm sourcing something safe but it can be
overridden by the MIME type, then I have a problem.
Perhaps we need an attribute on object that says to only render the
data if the server provided type and @type match? That way you
On 10/19/09 6:30 PM, Jonas Sicking wrote:
In particular I'm wondering what made other vendors decide to
support this.
I'd already asked this on this list, back in July. The relevant answers
(from the [whatwg] .tags on HTMLCollections thread):
On Tue, 14 Jul 2009, Maciej Stachowiak wrote:
On 10/28/09 2:59 AM, tali garsiel wrote:
1. As far as I know, Firefox and Webkit have a stall on demand behavior,
where a stylesheet blocks a script only if the script asks from style information.
You know wrong, sorry. Firefox has the behavior the spec describes;
webkit blocks the parser
On 10/29/09 9:20 AM, Michael A. Puls II wrote:
Despite that though, preventDefault() still works in
Firefox and Safari inside a keypress handler to prevent the char from
being inserted. So, I'm not exactly sure what's they're doing behind the
scenes.
Last I checked in Gecko, things looked
On 10/29/09 5:24 PM, Michael A. Puls II wrote:
I think so. The event target isn't changed by focus().
But, in Firefox, Safari and Opera, it's possible to change what element
the text is inserted into by changing the focus in 'keydown'.
Right; that happens because the keydown and keypress
On 10/29/09 10:16 PM, Maciej Stachowiak wrote:
WebKit also makes typing take effect as the default action for
keypress, at least for normal typing. It's more complicated when
international text input methods are in play.
Yeah, when IME is involved I have no idea what events are fired in Gecko
On 10/29/09 9:58 PM, Michael A. Puls II wrote:
But, in Firefox, Safari and Opera, it's possible to change what element
the text is inserted into by changing the focus in 'keydown'.
Right; that happens because the keydown and keypress events need not
fire on the same element and because the
On 10/30/09 6:41 PM, Michael A. Puls II wrote:
Is there a good way to solve that though? Or is that something that
should just be left as YMMV?
Well, you could require an alert to block all key event delivery to
the web page, right?
Would that be a desirable solution? Is that hard to
On 11/11/09 10:19 PM, David Bruant wrote:
This attribute have the following properties :
- It's only dependant on the hardware, the operating system and the
WebWorker implementation (thus, it is not dynamically computed by the
user agent at each call and two calls in the same
On 11/11/09 11:16 PM, Aryeh Gregor wrote:
I'm pretty sure that XHR is used for screen-scraping beyond Wikipedia,
Since it'd fail any time the data is not well-formed XML, I'd actually
expect such usage to be rare. It's not all that common to find XHTML
on the web that happens to be
On 11/11/09 11:57 PM, Aryeh Gregor wrote:
A number of popular web apps output mostly well-formed XML, as far as
I know: vBulletin, WordPress, etc.
I assume you meant mostly as in most of the pages are well-formed,
not pages are mostly well-formed, since the latter is useless, right?
I did a
On 11/12/09 12:49 PM, David Bruant wrote:
= You're perfectly right. I reformulate the definition of running
conditions (appearing in condition 2 and 3) as :
same memory available, same number of process running concurrently, no
other worker running working on the same document.
That doesn't
On 11/12/09 3:40 PM, David Bruant wrote:
= If you are comparing no other processes running and one other
process which is also completely cpu-bound running, you are not in what
I've called same running conditions. (because the number of concurrent
processes is different).
Yes, but your
On 11/12/09 7:24 PM, David Bruant wrote:
= I think it happens very often. While I'm writing this e-mail, no
process is running. About fifty processes are runnable, but not
running. They are passively waiting. My CPU is barely used.
Interesting. I have several browser processes using
On 11/12/09 9:21 PM, David Bruant wrote:
I was waiting for Firefox to stop freezing on the HTML5 spec page (it
freezes about one minute each time I visit the one-page version) and I
tried to think of a way to design this page in a way that wouldn't
freeze my browser.
Two easy ways to do this:
On 11/25/09 6:20 AM, Ian Hickson wrote:
- script calling a method implemented in native code on a host object
...
If this is a MUST, this seems like a possible compat issue depending on
whether the method is native or library-provided, at the very least.
There's also been talk at least
On 11/28/09 11:42 PM, Kenneth Russell wrote:
From a technical standpoint, it would be feasible to use the
WebGLUnsignedIntArray to access the Canvas's pixel data, and
assemble RGBA pixels into integer values using just JavaScript logical
operators.
I assume you meant JS bitwise operators? Do
On 11/28/09 3:44 PM, Jason Oster wrote:
The trouble with profiling my project is that it is a XULRunner
application, and does not run directly in web browsers as-is.
This is not an issue at all; any XULRunner application can be run in
Firefox directly (with the right command-line flags). I'm
On 11/29/09 12:15 AM, Kenneth Russell wrote:
I assume you meant JS bitwise operators? Do we have any indication that
this would be faster than four array property sets? The bitwise ops in JS
are not necessarily particulary fast.
Yes, that's what I meant. I don't have any data on whether this
On 11/29/09 1:20 PM, Jason Oster wrote:
Changeset 2b56c4771d5c reduced the number of pixel array elements
accessed by caching the 256px x 256px rooms within the stage map, and
passing the cached rooms to putImageData().
As opposed to doing what before the change?
The previous code used a
On 11/29/09 3:33 PM, Jason Oster wrote:
It might be important to note that this.fgmap.render() method also does some
tile decoding (to convert the SNES tile format into a usable bitmap), and
caches the results.
Does that make more sense? I know it is difficult to follow unfamiliar code,
but
On 11/29/09 11:22 PM, Oliver Hunt wrote:
The CanvasPixelArray implementation in WebKit has always matched the
spec and been a clamping bytearray, eg. one byte per channel, per
pixel.
I assume you mean the spec as it is now and not the spec as it was
when Gecko implemented get/putImageData?
On 11/29/09 11:22 PM, Oliver Hunt wrote:
I don't know where you're getting that idea from -- the clamping semantics for
CanvasPixelArray and WebGLUnsignedByteArray are identical.
Perhaps Kenneth included the rounding behavior (which seems to be
different to me from a brief look at
On 12/9/09 3:06 PM, James Robinson wrote:
On Wed, Dec 9, 2009 at 2:10 PM, James Robinson jam...@google.com
mailto:jam...@google.com wrote:
WebKit does not suspend script execution on requests for visual information if
stylesheets have not loaded
In theory, this is unobservable to
On 12/9/09 3:53 PM, James Robinson wrote:
Hence the in theory. If WebKit did suspend script execution on
requests for information that pending stylesheets might influence, then
theory would match practice. It currently does not (which I believe is
contrary to what the spec says). I'm curious
On 12/14/09 12:04 PM, John J Barton wrote:
Thanks, I understand that the global object in Javascript has a property
'window' which references the global object
It does not, in fact. It references a different object, which has a
pretty intimate relationship with the global object. But you
On 12/16/09 1:27 PM, Jan Fabry wrote:
function setFoo(val) { foo = val; }
function getFoo() { return foo; }
...
After the second postMessage, the worker receives a new object, also a
function, bound to a variable with the value 1.
What if getFoo were:
function getFoo() { return
On 12/17/09 12:34 AM, Jan Fabry wrote:
These three functions are equivalent to me.
They're meant to be, but also meant to be increasing in order of
analysis complexity.
If no scope is given, the global scope is used, and then it depends on the
state of the variables on the worker side.
On 12/17/09 12:48 AM, Boris Zbarsky wrote:
It seems very difficult to me to come up with a function cloning
solution that won't break in subtle ways when such functions are passed
to it...
I should clarify this. It seems to me eminently possible to clone
functions that only reference local
On 12/28/09 8:31 AM, Markus Ernst wrote:
printer-unfriendly way, such as using frames or a table layout, lacking
a printer stylesheet. Often the in-page print button just opens a
printer-friendly version of the page, without even invoking the print()
method.
The most common print button I run
On 12/28/09 9:54 AM, Michael A. Puls II wrote:
As for window.print(), what if it returns false if printing is not
supported?
It might be better as |true| (crappy API issues aside), because
otherwise if a page writes |if (window.print())| it'll get false in all
existing browsers, no?
-Boris
On 12/28/09 12:12 PM, Anne van Kesteren wrote:
Today someone printed a map for me so I could cycle towards some Apple
repair shop somewhere outside of town.
Ah, yes. Printing directions is another use case that I do in fact run
into.
This and your use case will be
more or less obsolete
On 12/31/09 3:07 PM, Adam Barth wrote:
Firefox and IE distinguish between about:blank documents and
documents for this purpose, if I remember correctly.
At the moment, Firefox in fact does not. See
On 1/13/10 11:52 AM, Maciej Stachowiak wrote:
Question: if you generate a document on the fly via early access, does
it get replaced when the about:blank task actually completes?
Yes. More precisely, the document is replaced, but the inner window is
not (the latter required for pages that
On 1/15/10 5:05 AM, Henri Sivonen wrote:
I've located a Mozilla test case that seems to depend on the event loop task
mapping of data: URL loads
(http://mxr.mozilla.org/mozilla-central/source/layout/base/tests/chrome/test_bug533845.xul).
Er... it does? Where?
Does anyone happen to have
101 - 200 of 1308 matches
Mail list logo
