> a few small steps away from being armed with > rocks and sling-shots.
First time I hear a T72 being described as a rock. And yes, these did see action, in case you missed it (if with little success, except against the Bradleys).
> But 10,000 civilians died
For comparison's sake, what are the civilian death figures for other hostile takeovers of countries with a population of about 20 million (say the non-Vichy part of France in World War II)?
> millions more are going to die because of > Depleted Uranium poisoning.
Depleted uranium is chemically about as poisonous as most other heavy metals that would be used for ordnance (the metal of choice for amunition was lead before DU came along, and we all know how safe lead is).
But nice try to stir up fears by mentioning "uranium" How about pointing to a scientific study of DU toxicity (some have been done, by opponents of DU, even, and found what I have said above) instead of pointing to propaganda?
1.4 is the version for _application_developers_ who need a stable API to base their applications on. 1.6 has changed some APIs, but is probably more stable (in terms of crashes) than 1.4....
Re:I don't understand their QA process
on
Mozilla 1.6 Released
·
· Score: 2, Informative
The problem here, quite frankly, is that this is a Windows-only bug and requires someone familiar with Windows and its resource issues to look at it. Most of the core developers don't know much about that stuff (in fact, I think most of them develop on Linux at this point....)
"2.0" will mean that the rendering engine has reached 2.0. It has nothing to do with any of the birds.
Re:But No One's mentioned the most important featu
on
Mozilla 1.6 Released
·
· Score: 1
> and pushed them at the right person at the right time
This is the problem. The writing of the release notes is not publicised to the developer community, so it's impossible to know either the person or the time.
> or they could be added after the release notes are initially published
Working on this, but sometimes this is like pulling teeth...
This particular bug got filed on a component that has no real owner at the moment (DOM events). No one who actually knows anything about the code was cced (this is the QA's fault). Due to rampant severity inflation, most bugs that claim to be major really aren't (this one is not, imo).
There is also the problem that about 50 bugs get reported each day (well, more like 120 get reported, but 70 get resolved as duplicate or invalid the same day). That's far more bugs than can be dealt with with the available development resources, unfortunately.
In general, the component a bug is reported on really determines how long it will take to fix it; some components are better owned than others....
So please do keep filing bugs; worst-case, that gives the chance that someone will see the bug and be annoyed by it and fix it.
Some nice changes in the back end. NTLM auth is relnoted, but there was also a lot of technical work on the layout engine. If nothing else, this release is about 10% faster than 1.5 at laying out web pages.
Re:But No One's mentioned the most important featu
on
Mozilla 1.6 Released
·
· Score: 1
> As listed in the Release notes mozilla's greatest feature yet:
Congrats. You've now noticed that none of the core engine changes, no matter how cool, ever make it into the release notes ("because they may be too scary for people"). But this crap makes it. .
> Once the *birds implement the same functionality > from a UI and extensions perspective, and the > same integration with each of the other > components as the current suite
Yeah, once this happens. ETA is at least 6 months for this (TBird is in 0.4, for goodness' sake).
Unfrtunately, Apache still defaults to text/plain for content whose type it does not know... IIS is much more sane and defaults to application/octet-stream. Apache's behavior (given IE ignoring MIME types) is the single biggest reason non-IE browsers are starting to ignore MIME types as well.
Because plugins are not images.... It would be possible to treat Flash as an image, I suppose; the problem is that no one has taken the time to write the code for that.
Perhaps the issue is that I think of things like schema-based validation as part of the "parser". It's not really, but schema-based validation would need to be implemented for the parser anyway, at which point XForms could just use it.
I think all the Mozilla developers fully understand the usefulness of XForms. What XForms proponents fail to understand, it seems, is that XForms relies on a whole slew of other XML technologies, many not well-supported by off-the-shelf XML parsers, that XForms is very complicated to implement, and that XForms is very difficult to author (instead of making the easy things easy and the hard things possible, it focuses on making the easy things and the hard things equally hard (a little easier than doing hard things with HTML forms, to be exact)).
So Mozilla developers would be just fine with having XForms support, but they are not about to write a new XML parser and hundreds of thousands of lines of form implementation code just to add another feature that almost no one really uses (quick, how many sites use XML documents at all? Answer: none that want to work in IE).
This is not to say that XForms would not be accepted into the tree if someone implemented it. It probably would be. It's just that spending time now reinventing wheels to implement XForms is pointless -- it can be done more quickly when the XML parser Mozilla uses (expat) is updated with the necessary features by its own development team...
> the example of the post you use is a memory > cache issue,
No, it's not. Mozilla happens to keep that data in the disk cache, because it's far to large and far too rarely accessed to keep in memory all the time. The only things kept in memory cache are no-store responses (for obvious reasons), uncacheable secure pages (same), and decoded images (for performance). Everything else lives in the disk cache.
I did read your post most carefully. Perhaps the issue here is that I happen to know what Mozilla uses the disk cache for OTHER than the caching defined in the HTTP RFC and you don't seem to have sufficient familiarity with the disk cache code involved?
Oh, OK. What gets sent to the address is all email associated with the bug, and it is publicly visible. I realize that some people are indeed not willing to file bugs on those terms; the next-best thing is to post to the mozilla newsgroups (netscape.public.mozilla.layout in this case), which can be done completely anonymously.
> margin-top: 10px;
Ah, there is the problem. The old <hr> code had some random spacing around the <hr> and any margin you set on it was added to that spacing. In the new code, that's all gone. An hr is just the same thing as a <div> except it has top and bottom margins set to 1em by default. Your CSS is overriding those 1em margins with 10px ones, which, with many font sizes, is not going to appreciably change the rendering. The upside is that you can now set the margins to whatever you want (whereas previously there was a hardcoded bottom limit). The downside is that the same CSS has different behavior in the different Mozilla builds. When I just apply that CSS I see exactly 10px of margin before and after the hr (vertically). You're saying you see no margins at all? Is there a page showing this problem I could look at?
In case you're curious, the change in question was made for http://bugzilla.mozilla.org/show_bug.cgi?id=38370 (and it resolved a dozen and a half or so bugs with the hr element; those blocked by that bug and a few others).
The border thing is exactly what you should use for the dotted effect, by the way...
Yes, you do, because they need to be available to session history.... People expect to be able to "back" to the result of a post request and not have it repost.
> Second, an external cache can most certainly > return whether an object is in cache or not
The problem is that you need to control whether it's in cache (like force "caching" of no-cache responses, for session history purposes, but nothing else). External caches won't let you do that.
> Third, an external cache program need not be > limited to HTTP.
Neither is an internal cache, of course... What point are you trying to make?
before 1.5 had all sorts of issues with auto margins, percentage margins, etc. It completely screws up changing display styles, positioning, and a whole slew of other things. In 1.5 and thereafter,
is just a block box.
I just tested, and a current builds display both percentage size and fixed size margins correctly. So I'm not sure what you're talking about. Given that, I can't explain what's going on without seeing your code. Which is where your bug report comes in.
Please file one at http://bugzilla.mozilla.org/enter_bug.cgi?product= Browser&format=guided
Most of the options are pretty self-explanatory and the page leads you through the process fairly well. It shouldn't be at all complicated to figure out what to fill in for the fields that are not already prefilled. The component should be "Layout".
> Why Mozilla developers think that Calendar and > Chatzilla
Chatzilla is a project done by two people who feel like working on it. It's not like they would be working on something else instead if they were not...
Calendar was done by a company that needed it. The amount of time the core network developers have spent on calendar is 0.
Please think about how the development process based on volunteer contributions works before spouting nonsense.
Slashdot Mirror
> Why did they think this was a good idea?
d gets.html
See http://www.ocallahan.org/mozilla/why-no-native-wi
> And after you've set browser.xul.error_pages.enabled to "true,"
Which you really shouldn't do. If you _do_ set it, don't file bugs about it. It's broken. We know. That's why it's a debug-only preference.
> a few small steps away from being armed with
> rocks and sling-shots.
First time I hear a T72 being described as a rock. And yes, these did see action, in case you missed it (if with little success, except against the Bradleys).
> But 10,000 civilians died
For comparison's sake, what are the civilian death figures for other hostile takeovers of countries with a population of about 20 million (say the non-Vichy part of France in World War II)?
> millions more are going to die because of
> Depleted Uranium poisoning.
Depleted uranium is chemically about as poisonous as most other heavy metals that would be used for ordnance (the metal of choice for amunition was lead before DU came along, and we all know how safe lead is).
But nice try to stir up fears by mentioning "uranium" How about pointing to a scientific study of DU toxicity (some have been done, by opponents of DU, even, and found what I have said above) instead of pointing to propaganda?
1.4 is the version for _application_developers_ who need a stable API to base their applications on. 1.6 has changed some APIs, but is probably more stable (in terms of crashes) than 1.4....
The problem here, quite frankly, is that this is a Windows-only bug and requires someone familiar with Windows and its resource issues to look at it. Most of the core developers don't know much about that stuff (in fact, I think most of them develop on Linux at this point....)
"2.0" will mean that the rendering engine has reached 2.0. It has nothing to do with any of the birds.
> and pushed them at the right person at the right time
This is the problem. The writing of the release notes is not publicised to the developer community, so it's impossible to know either the person or the time.
> or they could be added after the release notes are initially published
Working on this, but sometimes this is like pulling teeth...
This particular bug got filed on a component that has no real owner at the moment (DOM events). No one who actually knows anything about the code was cced (this is the QA's fault). Due to rampant severity inflation, most bugs that claim to be major really aren't (this one is not, imo).
There is also the problem that about 50 bugs get reported each day (well, more like 120 get reported, but 70 get resolved as duplicate or invalid the same day). That's far more bugs than can be dealt with with the available development resources, unfortunately.
In general, the component a bug is reported on really determines how long it will take to fix it; some components are better owned than others....
So please do keep filing bugs; worst-case, that gives the chance that someone will see the bug and be annoyed by it and fix it.
> But what earns this a +0.1 value?
Some nice changes in the back end. NTLM auth is relnoted, but there was also a lot of technical work on the layout engine. If nothing else, this release is about 10% faster than 1.5 at laying out web pages.
> As listed in the Release notes mozilla's greatest feature yet:
Congrats. You've now noticed that none of the core engine changes, no matter how cool, ever make it into the release notes ("because they may be too scary for people"). But this crap makes it. .
> Once the *birds implement the same functionality
> from a UI and extensions perspective, and the
> same integration with each of the other
> components as the current suite
Yeah, once this happens. ETA is at least 6 months for this (TBird is in 0.4, for goodness' sake).
Unfrtunately, Apache still defaults to text/plain for content whose type it does not know... IIS is much more sane and defaults to application/octet-stream. Apache's behavior (given IE ignoring MIME types) is the single biggest reason non-IE browsers are starting to ignore MIME types as well.
Because plugins are not images.... It would be possible to treat Flash as an image, I suppose; the problem is that no one has taken the time to write the code for that.
Perhaps the issue is that I think of things like schema-based validation as part of the "parser". It's not really, but schema-based validation would need to be implemented for the parser anyway, at which point XForms could just use it.
I think all the Mozilla developers fully understand the usefulness of XForms. What XForms proponents fail to understand, it seems, is that XForms relies on a whole slew of other XML technologies, many not well-supported by off-the-shelf XML parsers, that XForms is very complicated to implement, and that XForms is very difficult to author (instead of making the easy things easy and the hard things possible, it focuses on making the easy things and the hard things equally hard (a little easier than doing hard things with HTML forms, to be exact)).
So Mozilla developers would be just fine with having XForms support, but they are not about to write a new XML parser and hundreds of thousands of lines of form implementation code just to add another feature that almost no one really uses (quick, how many sites use XML documents at all? Answer: none that want to work in IE).
This is not to say that XForms would not be accepted into the tree if someone implemented it. It probably would be. It's just that spending time now reinventing wheels to implement XForms is pointless -- it can be done more quickly when the XML parser Mozilla uses (expat) is updated with the necessary features by its own development team...
> the example of the post you use is a memory
> cache issue,
No, it's not. Mozilla happens to keep that data in the disk cache, because it's far to large and far too rarely accessed to keep in memory all the time. The only things kept in memory cache are no-store responses (for obvious reasons), uncacheable secure pages (same), and decoded images (for performance). Everything else lives in the disk cache.
I did read your post most carefully. Perhaps the issue here is that I happen to know what Mozilla uses the disk cache for OTHER than the caching defined in the HTTP RFC and you don't seem to have sufficient familiarity with the disk cache code involved?
Oh, OK. What gets sent to the address is all email associated with the bug, and it is publicly visible. I realize that some people are indeed not willing to file bugs on those terms; the next-best thing is to post to the mozilla newsgroups (netscape.public.mozilla.layout in this case), which can be done completely anonymously.
> margin-top: 10px;
Ah, there is the problem. The old <hr> code had some random spacing around the <hr> and any margin you set on it was added to that spacing. In the new code, that's all gone. An hr is just the same thing as a <div> except it has top and bottom margins set to 1em by default. Your CSS is overriding those 1em margins with 10px ones, which, with many font sizes, is not going to appreciably change the rendering. The upside is that you can now set the margins to whatever you want (whereas previously there was a hardcoded bottom limit). The downside is that the same CSS has different behavior in the different Mozilla builds. When I just apply that CSS I see exactly 10px of margin before and after the hr (vertically). You're saying you see no margins at all? Is there a page showing this problem I could look at?
In case you're curious, the change in question was made for http://bugzilla.mozilla.org/show_bug.cgi?id=38370 (and it resolved a dozen and a half or so bugs with the hr element; those blocked by that bug and a few others).
The border thing is exactly what you should use for the dotted effect, by the way...
My point was that no XHTML is ever rendered in quirks mode by Mozilla. Ever. Unlike what your post implied.
> First, you don't cache POST requests.
Yes, you do, because they need to be available to session history.... People expect to be able to "back" to the result of a post request and not have it repost.
> Second, an external cache can most certainly
> return whether an object is in cache or not
The problem is that you need to control whether it's in cache (like force "caching" of no-cache responses, for session history purposes, but nothing else). External caches won't let you do that.
> Third, an external cache program need not be
> limited to HTTP.
Neither is an internal cache, of course... What point are you trying to make?
before 1.5 had all sorts of issues with auto margins, percentage margins, etc. It completely screws up changing display styles, positioning, and a whole slew of other things. In 1.5 and thereafter, is just a block box.
= Browser&format=guided
I just tested, and a current builds display both percentage size and fixed size margins correctly. So I'm not sure what you're talking about. Given that, I can't explain what's going on without seeing your code. Which is where your bug report comes in.
Please file one at http://bugzilla.mozilla.org/enter_bug.cgi?product
Most of the options are pretty self-explanatory and the page leads you through the process fairly well. It shouldn't be at all complicated to figure out what to fill in for the fields that are not already prefilled. The component should be "Layout".
> including a kitchensink ;)
Please stop spreading that fud. The kitchen sink patch was only checked in in the imaginations of the slashdot editors.
You did file bugs on this, right?
> The quirks/strict standards modes are triggered
d octypes.html
> by these doctypes respectively:
That's not at all true for Mozilla. Please see http://www.mozilla.org/docs/web-developer/quirks/
> Why Mozilla developers think that Calendar and
> Chatzilla
Chatzilla is a project done by two people who feel like working on it. It's not like they would be working on something else instead if they were not...
Calendar was done by a company that needed it. The amount of time the core network developers have spent on calendar is 0.
Please think about how the development process based on volunteer contributions works before spouting nonsense.
File bugs with testcases of things that are slow (_small_ testcases).
:(
And keep in mind that the price of correctness is sometimes speed.