> I tried several different ways to get the window to > open on the correct monitor, including my usual > trick of: open new window, drag to correct monitor, > and close. Open a new window again (which, > usually, opens on the correct window, but never > did under FF12)
Weird. I just tried exactly this in FF12, and it worked just fine.:(
If this is happening for you reliably, would you be willing to hunt down when the problem first appeared? If you are, there's a tool at http://harthur.github.com/mozregression/ that will automatically do a binary search on nightly builds. FF11 branched off the development trunk on 2011-12-20, and FF12 branched off on 2012-01-31. Presumably the problem appeared somewhere between those; with a binary search it should take 6 nightly build downloads to pin it down to a particular day.
I just tried Firefox 12 on Mac (10.6), and when I use Cmd+N to open a new window it opens on the same monitor as the window I have focused when I use the key combination.
Same thing for window.open. The window opens on the same monitor as the page where I clicked to trigger the window.open call.
Presumably you're opening your windows in some other way. How? I'd love to fix whatever issue you're running into, but I sort of need to reproduce it first...
For what it's worth, both Spidermonkey and V8 support those, and support is coming in other browsers.... Might still be fun for something like LAPACK, of course.
The problem, of course, is that the values of the counter in two clones of the same repo can be different, depending on exactly when they were cloned and when they pulled since then.... So the usability of the monotonic counter is pretty limited. And I say this as someone who spends a _lot_ of time with Mercurial.
The problem is not the patent disclosure. That's normal, and required for W3C members.
The problem is deliberately not joining the working group so they could disclose the patents as late as they could in the standards process, and thus make it take as long as possible to standardize touch events.
Again, the issue is whether Apple is actually "pushing for standards" or whether they're "delaying them as much as possible". In many cases, it's the latter.
> You need a concrete example of Apple actually > seeking to block web standards
I gave two concrete examples: -webkit-text-size-adjust and touch events.
They also volunteered to edit a few CSS specs (transitions, animations, transforms) and then did absolutely nothing. At this point other editors are working on it, but the specs won't be done until much later than otherwise; had Apple been honest that they had no plans to actually work on them, someone else would have picked them up much earlier.
They obviously can't _block_ standards forever, with the exception of patents they refuse to license (and in that situation the standard would be changed to work around the patent). But they're sure trying to make the sure the standards process is as slow as it can be in many cases.
> Which brings them no value.
Sure it brings them value. It keeps Google from forking WebKit. How is that not value for Apple?
> They ported to Windows, which doesn't really give > them much.
They ported to Windows because they thought they would get something out of it (e.g. maybe market share for Safari on Windows).
Apple is happy to work on the WebKit _implementation_.
They are not nearly as interested in actually working on _standards_.
Don't confuse "open source project" or even "open governance project" with "pushes for standards". Apple pushes for standards exactly when it suits them, in other cases it simply ignores them, and in yet other cases it actively obstructs them.
Apple pushes for standards? No, not really. For example, they're the only browser maker that does not employ _anyone_ to work on CSS specs. Google, Microsoft, Opera, Mozilla all have employees doing so. Apple? Not so much.
Also, Apple is explicitly refusing to submit things like -webkit-text-size-adjust for standardization (they claim it's their "proprietary technology"),.
Oh, and the little bit about waiting until touch events were just about standardized in the W3C (without Apple's involvement, because they chose to not join the working group), then declare they have patents on the standard as written and they refuse to license them. Had they joined the working group, they would have had to disclose this much earlier in the process, but it's in Apple's interest to have touch events working better in iOS than in web pages, so people create iOS-specific content and not HTML that works on all devices.
The result of all of which is that if you browse on a phone or tablet you constantly run into sites that require WebKit, and more often than not require Mobile Safari to render right.
Apple _does_ however try hard to make it _look_ like it's pushing for standards. I'll grant you that much. And it's not trying to monopolize the internet; just to slow down its development so it won't compete on a level playing field with iOS as an application delivery platform.
Plenty of websites break with each Chrome update, both because of changes to follow specs more closely and because bugs get introduced sometimes. Just like with Firefox.
The best way to keep that from happening is for some number of people to actually use the dev and beta builds of both browsers and report bugs....
> with some variation a software engineer at Mozilla is > making 75k, and a senior software engineer is > making 110k.
Those numbers are too low, especially if you look at total compensation (including bonuses), and not just salary.
I have no idea where the site you linked to is getting its numbers, but they're just flat-out wrong. If Mozilla was paying those rates in the Bay Area they wouldn't be able to hire people. The correct numbers for salary+bonus are probably close to 1.5x to 2x that much for those positions. Heck, Google is paying close to $100k plus stock grants plus bonuses to people more or less fresh out of college, last I checked. That's the general salary range involved here.
And again, Brendan is CTO, which is a heck of a lot more responsibility than being a Sr. software engineer, and at least in Mozilla's case involves some serious annoyances (like having to spend a bunch of time traveling and hence not being able to spend time with your family). Definitely not a 40-hour-a-week job.
Should a job like that pay $600k? I dunno. Should it pay at least $300k total compensation, given what the rest of the market looks like? I'd certainly think so! $100k would be way way too low.
You may not like that, but that's what market rates are....
Mozilla has employees in multiple locations, some of which have lower cost of living than Silicon Valley.
Mozilla also has a number of employees who happen to not be the CTO...
Was your question serious (as in, you really don't understand why different people in an organization might be paid different amounts), or are you just trolling?
But last of all.. The site you linked to just has bad data. For one thing, it lists a "high" of $116k, which is quite obviously bogus....
Do you really think $100k is the correct salary for a full-time job being CTO of a 500+ person company whose main business is technology? In the Bay Area?
This is not money Brendan and Mitchell are being paid as "directors"; this is money they are being paid as employees with quite specific jobs involving a good bit of responsibility.
The thing is, Mozilla's purpose is not to write software or get people to use its software. Its purpose is to create and promote and open web.
In many cases this involves writing software, and good software at that. But that's not strictly necessary, and it's definitely not sufficient to accomplish the main goal here.
No, the purpose is a free and open web and has been all along. Which is why Mozilla is doing various non-browser things (opposition to SOPA/PIPA, the Do-Not-Track header, B2G, BrowserID, etc, etc).
It just happened that while there was a browser monopoly the most important thing standing in the way of an open web was the existence of the browser monopoly, and the best way to fight it was to create a better browser.
There _is_ a fundamental problem with web technologies. It's called "web developers want more features". So browsers add features, and then you get combinatorial explosion of feature interactions and resulting complexity.
You can, of course, try to trash the old and invent something new. It's been tried; see XHTML2. Good luck with that!
> store a screenshot of the last view for each tab, and > have that screenshot fade to the actual view
Leads to bizarre flicker when the "actual view" has in fact changed (e.g. any site with a ticker, which are pretty common).
> Then decode any images that overlap the area one > screen above and below the current scroll > position.
That's what Gecko folks are working on now; it's not quite trivial to do. Especially not if image decoding is happening on the main thread, which is a bug of its own.
> Which is why a GUI program can employ tricks to > fake responsiveness.
Well, yes. The question is how much complexity the tricks introduce and what you have to give up as a result.
You do realize the images (and in fact entire parts of web pages) can be translucent, right? So if you want to fit in 16MB of RAM as you describe you need to not only purge the invisible parts of the web page but also purge the constituent parts that are being composited into the final image. And then you're in performance hell if the webpage has anything moving on it, because suddenly you have to rerender everything every frame instead of just recompositing.
> The mouse hovering over a tab means the tab is > likely to be the next one activated.
Decoding images for a tab can easily take hundreds of milliseconds. Doing that every time you hover over a tab is not really all that great either....
> Or in inactive tabs, you keep the images that are > currently scrolled onto the view and purge the rest.
Some browsers do that; it leads to flicker when scrolling. But yes, there are all sorts of ways to try to minimize memory usage here at the cost of worse responsiveness and performance.... And of course they _can_ be applied when you think you might be swapping. If you can detect that reliably; that's _hard_ to do, actually.
There's a significant difference between a police search of your home and inspections of nuclear sites by the IAEA.
The difference is that the latter only apply if your country signed the NPT. Article III of the NPT explicitly includes inspections by the IAEA for the NNWS signatories (of which Iran happens to be an example), as far as I can tell. This is in return for certain benefits Iran receives, such as other signatories being allowed to help them build nuclear reactors for peaceful use.
So if Iran is building nuclear weapons, it's in violation of its obligations under the NPT (Article II, to be exact). If it's refusing IAEA inspections, it's likewise in violation of said obligations (Article III), as far as I can tell. Now of course it's always able to withdraw from the NPT with 3 months notice (Article X), as North Korea did in 2003. Or it could have not signed the treaty at all (see Israel, India, Pakistan). But currently it's a signatory to the treaty.
So perhaps a better analogy is a restaurant that's not allowing food safety inspectors access that they think is needed for their inspection. Maybe the inspectors are abusing their position. Or maybe the restaurant is hiding something and should have its license pulled until it lets the inspectors have a look at what they want. Hard to say without looking at the exact things the inspectors want to see and why they want to see them...
Slashdot Mirror
> I tried several different ways to get the window to
> open on the correct monitor, including my usual
> trick of: open new window, drag to correct monitor,
> and close. Open a new window again (which,
> usually, opens on the correct window, but never
> did under FF12)
Weird. I just tried exactly this in FF12, and it worked just fine. :(
If this is happening for you reliably, would you be willing to hunt down when the problem first appeared? If you are, there's a tool at http://harthur.github.com/mozregression/ that will automatically do a binary search on nightly builds. FF11 branched off the development trunk on 2011-12-20, and FF12 branched off on 2012-01-31. Presumably the problem appeared somewhere between those; with a binary search it should take 6 nightly build downloads to pin it down to a particular day.
I just tried Firefox 12 on Mac (10.6), and when I use Cmd+N to open a new window it opens on the same monitor as the window I have focused when I use the key combination.
Same thing for window.open. The window opens on the same monitor as the page where I clicked to trigger the window.open call.
Presumably you're opening your windows in some other way. How? I'd love to fix whatever issue you're running into, but I sort of need to reproduce it first...
As far as old Firefox versions, they're all at ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/ (though granted, that's not terrible discoverable).
_Did_ the Firefox 11 you downloaded after editing the link fix the multi-monitor issue for you, by the way?
For what it's worth, both Spidermonkey and V8 support those, and support is coming in other browsers.... Might still be fun for something like LAPACK, of course.
Stefan, you know about http://www.khronos.org/registry/typedarray/specs/latest/ right?
The problem, of course, is that the values of the counter in two clones of the same repo can be different, depending on exactly when they were cloned and when they pulled since then.... So the usability of the monotonic counter is pretty limited. And I say this as someone who spends a _lot_ of time with Mercurial.
As a refutation to "pushing standards"? Why yes. What were you looking for, exactly? Assasinating heads of state?
The problem is not the patent disclosure. That's normal, and required for W3C members.
The problem is deliberately not joining the working group so they could disclose the patents as late as they could in the standards process, and thus make it take as long as possible to standardize touch events.
Again, the issue is whether Apple is actually "pushing for standards" or whether they're "delaying them as much as possible". In many cases, it's the latter.
> You need a concrete example of Apple actually
> seeking to block web standards
I gave two concrete examples: -webkit-text-size-adjust and touch events.
They also volunteered to edit a few CSS specs (transitions, animations, transforms) and then did absolutely nothing. At this point other editors are working on it, but the specs won't be done until much later than otherwise; had Apple been honest that they had no plans to actually work on them, someone else would have picked them up much earlier.
They obviously can't _block_ standards forever, with the exception of patents they refuse to license (and in that situation the standard would be changed to work around the patent). But they're sure trying to make the sure the standards process is as slow as it can be in many cases.
> Which brings them no value.
Sure it brings them value. It keeps Google from forking WebKit. How is that not value for Apple?
> They ported to Windows, which doesn't really give
> them much.
They ported to Windows because they thought they would get something out of it (e.g. maybe market share for Safari on Windows).
Apple is happy to work on the WebKit _implementation_.
They are not nearly as interested in actually working on _standards_.
Don't confuse "open source project" or even "open governance project" with "pushes for standards". Apple pushes for standards exactly when it suits them, in other cases it simply ignores them, and in yet other cases it actively obstructs them.
Apple pushes for standards? No, not really. For example, they're the only browser maker that does not employ _anyone_ to work on CSS specs. Google, Microsoft, Opera, Mozilla all have employees doing so. Apple? Not so much.
Also, Apple is explicitly refusing to submit things like -webkit-text-size-adjust for standardization (they claim it's their "proprietary technology"),.
Oh, and the little bit about waiting until touch events were just about standardized in the W3C (without Apple's involvement, because they chose to not join the working group), then declare they have patents on the standard as written and they refuse to license them. Had they joined the working group, they would have had to disclose this much earlier in the
process, but it's in Apple's interest to have touch events working better in iOS than in web pages, so people create iOS-specific content and not HTML that works on all devices.
The result of all of which is that if you browse on a phone or tablet you constantly run into sites that require WebKit, and more often than not require Mobile Safari to render right.
Apple _does_ however try hard to make it _look_ like it's pushing for standards. I'll grant you that much. And it's not trying to monopolize the internet; just to slow down its development so it won't compete on a level playing field with iOS as an application delivery platform.
Plenty of websites break with each Chrome update, both because of changes to follow specs more closely and because bugs get introduced sometimes. Just like with Firefox.
The best way to keep that from happening is for some number of people to actually use the dev and beta builds of both browsers and report bugs....
> with some variation a software engineer at Mozilla is
> making 75k, and a senior software engineer is
> making 110k.
Those numbers are too low, especially if you look at total compensation (including bonuses), and not just salary.
I have no idea where the site you linked to is getting its numbers, but they're just flat-out wrong. If Mozilla was paying those rates in the Bay Area they wouldn't be able to hire people. The correct numbers for salary+bonus are probably close to 1.5x to 2x that much for those positions. Heck, Google is paying close to $100k plus stock grants plus bonuses to people more or less fresh out of college, last I checked. That's the general salary range involved here.
And again, Brendan is CTO, which is a heck of a lot more responsibility than being a Sr. software engineer, and at least in Mozilla's case involves some serious annoyances (like having to spend a bunch of time traveling and hence not being able to spend time with your family). Definitely not a 40-hour-a-week job.
Should a job like that pay $600k? I dunno. Should it pay at least $300k total compensation, given what the rest of the market looks like? I'd certainly think so! $100k would be way way too low.
You may not like that, but that's what market rates are....
Mozilla has employees in multiple locations, some of which have lower cost of living than Silicon Valley.
Mozilla also has a number of employees who happen to not be the CTO...
Was your question serious (as in, you really don't understand why different people in an organization might be paid different amounts), or are you just trolling?
But last of all.. The site you linked to just has bad data. For one thing, it lists a "high" of $116k, which is quite obviously bogus....
I would also be very very surprised by that. Please do cite, because so far this looks like pretty basic FUD to me...
Do you really think $100k is the correct salary for a full-time job being CTO of a 500+ person company whose main business is technology? In the Bay Area?
This is not money Brendan and Mitchell are being paid as "directors"; this is money they are being paid as employees with quite specific jobs involving a good bit of responsibility.
Citation please? I'm not aware of either Gary Kovacs or John Lilly traveling in a private jet during their tenures as CEO....
The thing is, Mozilla's purpose is not to write software or get people to use its software. Its purpose is to create and promote and open web.
In many cases this involves writing software, and good software at that. But that's not strictly necessary, and it's definitely not sufficient to accomplish the main goal here.
No, the purpose is a free and open web and has been all along. Which is why Mozilla is doing various non-browser things (opposition to SOPA/PIPA, the Do-Not-Track header, B2G, BrowserID, etc, etc).
It just happened that while there was a browser monopoly the most important thing standing in the way of an open web was the existence of the browser monopoly, and the best way to fight it was to create a better browser.
Google promised they'd drop H.264 in Chrome... and then never did. Recent queries about the state of that promise are met with curious silence.
There _is_ a fundamental problem with web technologies. It's called "web developers want more features". So browsers add features, and then you get combinatorial explosion of feature interactions and resulting complexity.
You can, of course, try to trash the old and invent something new. It's been tried; see XHTML2. Good luck with that!
> store a screenshot of the last view for each tab, and
> have that screenshot fade to the actual view
Leads to bizarre flicker when the "actual view" has in fact changed (e.g. any site with a ticker, which are pretty common).
> Then decode any images that overlap the area one
> screen above and below the current scroll
> position.
That's what Gecko folks are working on now; it's not quite trivial to do. Especially not if image decoding is happening on the main thread, which is a bug of its own.
> Which is why a GUI program can employ tricks to
> fake responsiveness.
Well, yes. The question is how much complexity the tricks introduce and what you have to give up as a result.
You do realize the images (and in fact entire parts of web pages) can be translucent, right? So if you want to fit in 16MB of RAM as you describe you need to not only purge the invisible parts of the web page but also purge the constituent parts that are being composited into the final image. And then you're in performance hell if the webpage has anything moving on it, because suddenly you have to rerender everything every frame instead of just recompositing.
> The mouse hovering over a tab means the tab is
> likely to be the next one activated.
Decoding images for a tab can easily take hundreds of milliseconds. Doing that every time you hover over a tab is not really all that great either....
> Or in inactive tabs, you keep the images that are
> currently scrolled onto the view and purge the rest.
Some browsers do that; it leads to flicker when scrolling. But yes, there are all sorts of ways to try to minimize memory usage here at the cost of worse responsiveness and performance.... And of course they _can_ be applied when you think you might be swapping. If you can detect that reliably; that's _hard_ to do, actually.
The "is about" thing is pretty hard, yeah. We're not good at time-travel.
And decompressing after the switch is _possible_ but leads to user-visible flicker...
There's a significant difference between a police search of your home and inspections of nuclear sites by the IAEA.
The difference is that the latter only apply if your country signed the NPT. Article III of the NPT explicitly includes inspections by the IAEA for the NNWS signatories (of which Iran happens to be an example), as far as I can tell. This is in return for certain benefits Iran receives, such as other signatories being allowed to help them build nuclear reactors for peaceful use.
So if Iran is building nuclear weapons, it's in violation of its obligations under the NPT (Article II, to be exact). If it's refusing IAEA inspections, it's likewise in violation of said obligations (Article III), as far as I can tell. Now of course it's always able to withdraw from the NPT with 3 months notice (Article X), as North Korea did in 2003. Or it could have not signed the treaty at all (see Israel, India, Pakistan). But currently it's a signatory to the treaty.
So perhaps a better analogy is a restaurant that's not allowing food safety inspectors access that they think is needed for their inspection. Maybe the inspectors are abusing their position. Or maybe the restaurant is hiding something and should have its license pulled until it lets the inspectors have a look at what they want. Hard to say without looking at the exact things the inspectors want to see and why they want to see them...