See the bugs on the issue. In short, sites commonly test whether document.all exists to test for IE. Then if they detect it exists they commonly assume the following:
1) IE event model (which is totally different from
the W3C one). 2) VBScript support 3) IE CSS extensions support (filter, expression,
etc).
and so forth. So implementing document.all would in fact break a number of sites that work fine with Mozilla right now unless a whole slew of other IE stuff got implemented too.
Note that IE does getElementById fine, so you can just use the getElementById code for both browser....
SVG 1.2 is likely to be a disaster in all browsers, since the spec is focusing on creating an application delivery language rather than a graphics language (see the support for opening and writing to network sockets, for example).
90% of the changes for Minimo have been made to the core engine used by the desktop Mozilla as well. The remaining changes involve things like ifdef-ing out XUL support. Desktop Mozilla's footprint has benefited quite a bit from this project.
That support is already there. Since there is no "standard" app for telnet (or ssh), Mozilla doesn't have one preset, but you could set one yourself. It works on Windows because on Windows there is a standard API to ask the OS what app should handle a protocol. Linux has no such beastie, though on modern GNOME systems the gtk2 builds will pick up the gnome-vfs preferences for this (which of course sucks if you happen to be a KDE user; this is where an actual working OpenDesktop thing would be nice).
The point (briefly and ineptly mentioned in the article) is that if you _do_ have only one photon leaving at a time (such experiments have in fact been performed) you get the same diffraction pattern.
So a single photon somehow passes through all four slits at once and interferes with itself.
Unless you try to detect which slit it's going through -- then the pattern disappears.
Now all this can be explained in terms of wave functions, state superposition, and wave function collapse when a measurement occurs. But the point is, that "wave function collapse when a measurement occurs" and "parallel universe with shadow photons" are about equally bizarre phenomena. And assuming they give the same predictions for results of experiments, neither is more "correct" than the other.
Of course this article doesn't cover the question of whether the two theories give the same predictions... which is where the pseudo-scientific part comes in.
> if I wanted some kind of megalomaniac > "application development platform" I will use > Python, thank you very much.
See http://www-106.ibm.com/developerworks/webservices/ library/co-pyxp1.html
Seriously, see http://mab.mozdev.org/ for the sort of things that can be done with an "application development platform" and compare it to the HTML Amazon search stuff...
Everyone is doing it, yes. The difference is that if you're a monopoly, then it's ILLEGAL to do it, whereas it is legal to do it if you're not a monopoly. Being a monopoly is not illegal per se; abusing the monopoly power is. That's the extent of US anti-trust legislation, essentially.
I didn't say Debian not being able to use the branding is by design. I just pointed out that if _I_ were the one deciding whether they can use it, I would decide they can't, without some work on both sides to make the builds be more similar. But I'm not doing the deciding, so....
> and the ability to make slight tweaks to the source code
It's not quite that benign, unfortunately... as of 1.6, at least, Debian is shipping some changes to their custom Mozilla build that correspond to bugs that the main Mozilla tree has wontfixed (because they felt that those changes were bad for the project in particular and Internet standards in general).
As for Debian users posting bugs in the Mozilla.org database, we get a few dozen after every release. They're almost all due to changes Debian has made in their version of the builds... Figuring this out usually takes quite a bit of digging.
This is not to say that they break things on purpose, and they do make a bunch of changes that are beneficial to their users. But the point is that their builds have sufficiently different functionality that confusion of them with the Mozilla.org builds by users _does_ use up a good bit of QA and developer time.
I suspect that's exactly what will end up happening. Debian's modified firefox will be called just that "Debian Firefox", and everyone will be happy...
This has nothing to do with the GPL. Firefox isn't even (solely) GPLed. This is a trademark matter.
Just like you can create a fork of OpenBSD (because that's a licensing issue), but you can't call it Unix without getting permission from the trademark holder (because Unix is a trademark).
More on the topic of Debian changes to Mozilla... open up http://ftp.debian.org/debian/pool/main/m/mozilla/m ozilla_1.6-3.diff.gz (which is the full set of changes they made to 1.6). Search for "alttext". Note that that change was expressly rejected from the Mozilla trunk and that Debian is shipping it. Now is this considered rewriting in "bad ways"? Mozilla.org certainly thought this patch bad (the bug is marked WONTFIX in bugzilla.mozilla.org, because the entire proposed change was considered bad for Mozilla, not just the specific patch).
> We all know Debian is not going to re-write > FireFox in bad ways,
We do? I've had to mark a number of Mozilla bug reports invalid because they were reported against Debian builds and the Debian package maintainers had just gone and broken things that were working perfectly fine in the mozilla.org builds...
1998 figures on military budgets (from http://www.cdi.org/issues/wme/spend.html):
US $265 billion Russia $48 billion Japan $45 billion France $38 billion UK $33 billion Germany $32 billion China $32 billion
Yeah. No military to take up financing. Just 1.5 times the military budget of the UK.
Japan has one of the largest and best-equipped armies in the world, in fact . It's just called a defence force and theoretically prohibited from taking offensive action by the Japanese constitution.
> Even the final order form page is sent over HTTP, > but the form POST is set to use HTTPS.
Unfortuantely, you have no clue where the form is going to be submitted to.... Just looking at the source is not enough -- there can be an onsubmit handler defined in one of the dozen scripts linked into that page that rewrites the action URI to a (HTTPS, sure) URI pointing at some other server. Like the server of the guy who just performed a man-in-the-middle attack on the unencrypted data channel you and the store were using...
The only way to prevent this is to serve the page the uset types the credit card number in as https and have the user check that _that_ page is actually what it's claiming to be.
All this apart from the fact that if you type any text into a web page that web page can immediately phone the text home (using toys like XMLHttpRequest, SOAP, etc). So don't EVER type a credit card number in a page whose origin is not guaranteed.
> good to know that platform file/save dialogs are > on the TODO
They're not on the TODO. They're _DONE_ on Mac and Windows. On Linux, it may get done once we switch fully over to gtk2 -- the gtk1 filepicker does such a poor job of handling non-ascii filenames that it was simply not an option.
> I see they're going to implement native widgets > (as an option)
Where do you see that? "Native widget integration" means using platform theme apis, when available (eg WinXP) to _paint_ the widgets (basically paint a native widget into a bitmap and then paint that into the right places, applying the right z-index, opacity, etc to it as needed).
"They" has been one person up to now, basically. He recently landed a major rewrite of most of svg that should make it possible to move towards actually enabling it by default (especially if the libart licensing issues, which are what's prevented it from being turned on as far as I know, have gotten resolved).
Slashdot Mirror
> why can't they support the "all" collection?
See the bugs on the issue. In short, sites commonly test whether document.all exists to test for IE. Then if they detect it exists they commonly assume the following:
1) IE event model (which is totally different from
the W3C one).
2) VBScript support
3) IE CSS extensions support (filter, expression,
etc).
and so forth. So implementing document.all would in fact break a number of sites that work fine with Mozilla right now unless a whole slew of other IE stuff got implemented too.
Note that IE does getElementById fine, so you can just use the getElementById code for both browser....
SVG 1.2 is likely to be a disaster in all browsers, since the spec is focusing on creating an application delivery language rather than a graphics language (see the support for opening and writing to network sockets, for example).
> but also backport changes to the main CVS trunk
They do, as it happens. As you could verify yourself by looking at the CVS logs.
90% of the changes for Minimo have been made to the core engine used by the desktop Mozilla as well. The remaining changes involve things like ifdef-ing out XUL support. Desktop Mozilla's footprint has benefited quite a bit from this project.
By "mozilla" they mean "The mozilla rendering engine", not "Mozilla the application suite".
;)
In fact, this is probably significantly smaller than Firefox, since it disables things like XUL, as I recall. Not something Firefox can do...
That support is already there. Since there is no "standard" app for telnet (or ssh), Mozilla doesn't have one preset, but you could set one yourself. It works on Windows because on Windows there is a standard API to ask the OS what app should handle a protocol. Linux has no such beastie, though on modern GNOME systems the gtk2 builds will pick up the gnome-vfs preferences for this (which of course sucks if you happen to be a KDE user; this is where an actual working OpenDesktop thing would be nice).
The point (briefly and ineptly mentioned in the article) is that if you _do_ have only one photon leaving at a time (such experiments have in fact been performed) you get the same diffraction pattern.
So a single photon somehow passes through all four slits at once and interferes with itself.
Unless you try to detect which slit it's going through -- then the pattern disappears.
Now all this can be explained in terms of wave functions, state superposition, and wave function collapse when a measurement occurs. But the point is, that "wave function collapse when a measurement occurs" and "parallel universe with shadow photons" are about equally bizarre phenomena. And assuming they give the same predictions for results of experiments, neither is more "correct" than the other.
Of course this article doesn't cover the question of whether the two theories give the same predictions... which is where the pseudo-scientific part comes in.
> if I wanted some kind of megalomaniac
/ library/co-pyxp1.html
> "application development platform" I will use
> Python, thank you very much.
See http://www-106.ibm.com/developerworks/webservices
Seriously, see http://mab.mozdev.org/ for the sort of things that can be done with an "application development platform" and compare it to the HTML Amazon search stuff...
MPL (the Mozilla license) is less restrictive than GPL, so they would not have to release their source, in fact.
The option is there, under the "Advanced" button in account settings..... where it belongs.
Everyone is doing it, yes. The difference is that if you're a monopoly, then it's ILLEGAL to do it, whereas it is legal to do it if you're not a monopoly. Being a monopoly is not illegal per se; abusing the monopoly power is. That's the extent of US anti-trust legislation, essentially.
Great Britain and Germany were allies economically (indeed, each other's largest trading partners) in 1914. Didn't stop them.
I didn't say Debian not being able to use the branding is by design. I just pointed out that if _I_ were the one deciding whether they can use it, I would decide they can't, without some work on both sides to make the builds be more similar. But I'm not doing the deciding, so....
> anybody can distribute it, it can't be controlled.
Anyone can distribute the code. You just can't claim to be Mozilla.org while doing so.
By the way, what patches have you contributed to Mozilla?
> and the ability to make slight tweaks to the source code
It's not quite that benign, unfortunately... as of 1.6, at least, Debian is shipping some changes to their custom Mozilla build that correspond to bugs that the main Mozilla tree has wontfixed (because they felt that those changes were bad for the project in particular and Internet standards in general).
As for Debian users posting bugs in the Mozilla.org database, we get a few dozen after every release. They're almost all due to changes Debian has made in their version of the builds... Figuring this out usually takes quite a bit of digging.
This is not to say that they break things on purpose, and they do make a bunch of changes that are beneficial to their users. But the point is that their builds have sufficiently different functionality that confusion of them with the Mozilla.org builds by users _does_ use up a good bit of QA and developer time.
I suspect that's exactly what will end up happening. Debian's modified firefox will be called just that "Debian Firefox", and everyone will be happy...
This has nothing to do with the GPL. Firefox isn't even (solely) GPLed. This is a trademark matter.
Just like you can create a fork of OpenBSD (because that's a licensing issue), but you can't call it Unix without getting permission from the trademark holder (because Unix is a trademark).
More on the topic of Debian changes to Mozilla... open up http://ftp.debian.org/debian/pool/main/m/mozilla/m ozilla_1.6-3.diff.gz (which is the full set of changes they made to 1.6). Search for "alttext". Note that that change was expressly rejected from the Mozilla trunk and that Debian is shipping it. Now is this considered rewriting in "bad ways"? Mozilla.org certainly thought this patch bad (the bug is marked WONTFIX in bugzilla.mozilla.org, because the entire proposed change was considered bad for Mozilla, not just the specific patch).
> We all know Debian is not going to re-write
> FireFox in bad ways,
We do? I've had to mark a number of Mozilla bug reports invalid because they were reported against Debian builds and the Debian package maintainers had just gone and broken things that were working perfectly fine in the mozilla.org builds...
1998 figures on military budgets (from http://www.cdi.org/issues/wme/spend.html):
US $265 billion
Russia $48 billion
Japan $45 billion
France $38 billion
UK $33 billion
Germany $32 billion
China $32 billion
Yeah. No military to take up financing. Just 1.5 times the military budget of the UK.
Japan has one of the largest and best-equipped armies in the world, in fact . It's just called a defence force and theoretically prohibited from taking offensive action by the Japanese constitution.
> Even the final order form page is sent over HTTP, > but the form POST is set to use HTTPS.
Unfortuantely, you have no clue where the form is going to be submitted to.... Just looking at the source is not enough -- there can be an onsubmit handler defined in one of the dozen scripts linked into that page that rewrites the action URI to a (HTTPS, sure) URI pointing at some other server. Like the server of the guy who just performed a man-in-the-middle attack on the unencrypted data channel you and the store were using...
The only way to prevent this is to serve the page the uset types the credit card number in as https and have the user check that _that_ page is actually what it's claiming to be.
All this apart from the fact that if you type any text into a web page that web page can immediately phone the text home (using toys like XMLHttpRequest, SOAP, etc). So don't EVER type a credit card number in a page whose origin is not guaranteed.
> good to know that platform file/save dialogs are
> on the TODO
They're not on the TODO. They're _DONE_ on Mac and Windows. On Linux, it may get done once we switch fully over to gtk2 -- the gtk1 filepicker does such a poor job of handling non-ascii filenames that it was simply not an option.
> Firefox 1.0 will not have this problem
They're going to multithread the layout engine? First I hear of it. What makes you think this is true?
> I see they're going to implement native widgets
> (as an option)
Where do you see that? "Native widget integration" means using platform theme apis, when available (eg WinXP) to _paint_ the widgets (basically paint a native widget into a bitmap and then paint that into the right places, applying the right z-index, opacity, etc to it as needed).
"They" has been one person up to now, basically. He recently landed a major rewrite of most of svg that should make it possible to move towards actually enabling it by default (especially if the libart licensing issues, which are what's prevented it from being turned on as far as I know, have gotten resolved).