Firefox on Mac textarea edit bug open since 2005
bugzilla.mozilla.org
bugzilla.mozilla.org
""" FIRST OFFICER: Don't you think it rains more? In this area, here?
The first officer must have thought long and hard before making that comment. [...] Among Korean Air flight crews, the expectation on layovers used to be that the junior officers would attend to the captain to the point of making him dinner or purchasing him gifts. As one former Korean Air pilot puts it [...] "the captain is in charge and does what he wants, when he likes, how he likes, and everyone else sits quietly and does nothing."
[...]
So when the first officer says, "Don't you think it rains more? In this area, here?" we know what he means by that:
Captain. You have committed us to visual approach, with no backup plan, and the weather outside is terrible. You think that we will break out of the clouds in time to see the runway. But what if we don't? It's pitch-black outside and pouring rain and the glide scope is down. """
The plane crashes not because of any individual error, but rather because the culture aboard the plane is weak in a tragically important area plane flight: communicating errors.
So imagine my surprise when I see this post on the bug tracker: "Ehsan, are you going to be able to pick this up again? If not, let's find a new owner."
In an open source project, you don't pay people in money. They're paid in intrinsic motivation. For that reason, it can be very dangerous to do things that would be commonplace in a business. For example, pulling someone off a task and reassigning it to someone else. I would read that post as "Ehsan, can you fix this or should I assign it to someone else?"
And I would read his reply as "No, I don't think I can without extra help". But no help comes, because the discussion is wrapped in social code to avoid appearing incapable or ordering someone around, neither of which are really acceptable in an open source project.
I suspect that this represents a general trend, and much of the reason why good design has come so late to the picture for Linux, when it seems to fall so naturally out of everything Apple touches. The culture in open source is a kind of loose-knit collective individualism, which means leadership in open source looks a lot like gardening: your main function is to tend the soil and stop the plants from strangling each other.
But design necessarily requires autocratic leadership - a person or persons whose vision for the product subsumes the priorities of any individual working on it. As a thought experiment, imagine if everyone's favourite ex-Apple CEO was faced with this bug. I can't help but imagine him kicking in someone's door and screaming "Why isn't it fixed? What do you need? Don't understand XBL? Here's the guy who writes the event handler. Neither of you are leaving until it's done. Namaste."
That's a good way to lose contributors, but it would get the bug fixed. I don't think Mozilla would necessarily be a better organisation with more screaming but, like Korean culture has a characteristic failure mode (problems that would have been impolite to fix), open source has its own characteristic failure mode: a problem that would have been solved if someone cared enough.
I'm not sure if Ehsan is or isn't paid, but many open source developers are paid. The Mozilla corporation itself has over 200 employees, although I'm not sure what percentage are developers.
Anyway, I wouldn't say this really has much to do with it being an open source project. I've had the same thing come up in many closed source projects I've worked on for big companies. Sometimes the code's very complex. Maybe you can fix the bug, but it would take 100 hours of learning the code to really figure out the correct solution that handles all the ins and outs and edge cases. That's a hard investment to justify quite often for a single bug unless it's a big one.
Simply because the software company operates in the open does not mean that they are more likely to let bugs sit for a while. I've worked on closed-source software that suffered from the exact same problems.
The right target of blame here is XBL. XBL deserves criticism for being heavyweight, overengineered, and still not being flexible enough despite its enormous complexity. But this is not an issue of Mozilla intentionally ignoring platform conventions. They are trying to adopt the OS-native conventions and are facing limitations in their platform.
As we all know, the standard OS X shortcut for moving backward and forward is Cmd+[ and Cmd+]. The Cmd+Left/Right shortcut for moving backward/forward is decade-old cruft (even though Safari still conditionally supports it).
If the Mozilla platform cannot handle supporting this cruft on top of the standard Cmd+Left/Right text editing behavior, then at the very least remove the cruft. Instead, the problem is allowed to linger for years and years as people bicker back and forth about what to do about it. That shouldn't be acceptable to anyone.
Cmd-Left and Cmd-Right are necessary.
(Google Chrome has actually Cmd-[ and Cmd-] as back and forward even with my German keyboard layout – which is quite dumb and shows that they don’t seem to care much for localization. Cmd-[ translates to Alt-Cmd-5 on a German keyboard.)
The sense of entitlement when it comes to something created and used freely, solely for the purpose of making the world better, sometimes simply astounds me.
I don’t think something should be protected from criticism just because it’s free. Just because it’s open source doesn’t mean I have to try to fix it before I’m allowed to criticize it. I can simply recognize shoddy workmanship and move on.
1. BROKEN: textarea in a Disqus comment editor (as suggested by a comment on the bugtracker). Cmd-left and Cmd-right go back and forward in browser history, unless there is no history in that direction, in which case they go the the beginning and end of the line.
2. BROKEN: gmail compose textarea. Cmd-left and Cmd-right do nothing at all.
3. WORKING: textarea for Hacker News commenting. Cmd-left and Cmd-right work as expected, moving to the beginning and end of the line regardless of browser history.
I wonder if Firefox ignores a custom ~/Library/KeyBindings/DefaultKeyBinding.dict ?
eg. BBEdit is supposedly Carbon and not Cocoa and it seems to ignore anything in DefaultKeyBinding.dict.
My simple bindings do seem to work in Safari but not in Chrome.
Try the infamous plugin object reframe bug [1]. 10 years.
Granted, it's a very nasty bug inside code that has changed a lot over the years, and deep architectural understanding is necessary in order to solve it. But the fact that such a bug is still in the open says a lot.
[1] - https://bugzilla.mozilla.org/show_bug.cgi?id=90268
(edit: I haven't followed the bug in a while but apparently Josh Aas made some groundbreaking progress over the past few weeks. Looks pretty good.)
The funny thing is that even if the problem lies within XBL, it could be easily fixed for 99% of the cases through a small JavaScript code injection...
"Lazarus securely auto-saves all forms as you type, so after a crash, server timeout, or whatever, you can go back to the form, right click, "recover form", and breathe a sigh of relief."