Firefox on Mac textarea edit bug open since 2005(bugzilla.mozilla.org)
bugzilla.mozilla.org
Firefox on Mac textarea edit bug open since 2005
https://bugzilla.mozilla.org/show_bug.cgi?id=289384
11 comments
I don't think this is a fair comparison.
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.
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.
> In an open source project, you don't pay people in money.
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.
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.
Ehsan fixed several contentEditable bugs for me to make the Google Spreadsheets formula bar and formula highlighting work in FireFox. I created those features in my 20% time and the initial release supported only Chrome and IE. He was the biggest help in making it work in FireFox.
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.
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.
Mozilla has over 500 employees.
Ehsan's a Mozilla employee, yes.
I think maybe you're projecting here, a 5 year old bug isn't that uncommon. I've followed bugs that old from Microsoft as well. I'm not sure about Apple, you have to pay $100 to see their bug tracker.
This is not, as the other comments on this post are suggesting, an issue with Firefox intentionally ignoring platform conventions. Safari has the exact same behavior on the Mac as Firefox — Cmd+Left goes back, and Cmd+Right goes forward, except in textareas, when Cmd+Left goes to the beginning of the line and Cmd+Right goes to the end of the line. This is an ugly technical issue with XBL that is preventing Mozilla from implementing the behavior that they need to on the Mac for contenteditable areas.
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.
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.
The real problem is that Mozilla lacks a Mac OS X usability advocate with the authority to expedite sensible solutions to these kinds of problems.
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.
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.
You mean the standard OS X shortcuts if you use a US keyboard, right? The shortcuts on a German keyboard (which does not have [ and ] keys) for back and forward are Shift-Cmd-Ö and Shif-Cmd-Ä (that’s using Safari), clearly inferior to Cmd-Left and Cmd-Right.
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.)
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.)
You know it's an open source project and you could go ahead and add code yourself to support a more sensible shortcut on German keyboards, right?
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.
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 can’t, actually, I’m not a developer, but that’s very much besides the point.
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.
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.
Can others here verify if the bug exists for them? I just updated Firefox again and now I get different textarea behavior:
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.
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.
The title for the submission is wrong. This is not about textareas, but contenteditable elements (rich text editing).
I've had the same problem with the backspace. When hitting backspace while editing, often (not always) the browser goes to previous page (in history), so I lose my edits. Going forward does not give me back my edits.
If this poses enough of a problem, you might consider disabling the "backspace navigates back" behavior by setting browser.backspace_action in about:config to 2 and just using the shortcuts with modifiers (Cmd+[ or Cmd+Left, et al) or three-finger swipe. This is actually the default way interaction works on Linux builds.
This has been the source of much pain on my part on more than one occasion.
It should only go back to previous page if the input is not focused. I've been bitten by this myself a few times and have developed a habbit to check if some input is focused before pressing backspace.
So, the crux of the issue is that a cross platform program is trying to use a platform keystroke convention as some other function. This type of stuff really shows what happens when you violate someone's expectations of how apps work on their OS. Squeak is another example of a program that is it's own thing.
I wonder if Firefox ignores a custom ~/Library/KeyBindings/DefaultKeyBinding.dict ?
I wonder if Firefox ignores a custom ~/Library/KeyBindings/DefaultKeyBinding.dict ?
I was under the impression that those bindings really only work with Cocoa applications/objects.
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.
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.
It does, as far as I can tell. (Although it's possible that this has changed in more recent versions, I haven't been able to test this.) One of the first things I do on a new Mac is set custom keybindings this way, and some apps just don't listen to it.
You think that's epic?
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.)
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.)
I hear these open source projects accept patches...
Mozilla made $100 million (in 2009), primarily through revenue from the built-in Google search. I dare say the onus is on them to fix their own browser, seeing as it sustains revenues for a huge organization.
Or you can ask for a refund of what you paid for the browser.
That's one of the reasons I can't stand using Firefox on OS X.
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...
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...
Think that's a long time? Check out how many bugs Eclipse has, that were first reported over 10 years ago:
https://bugs.eclipse.org/bugs/buglist.cgi?type0-1-0=equals;o...
You can mitigate the problem by installing Lazarus (https://addons.mozilla.org/en-US/firefox/addon/lazarus-form-...).
"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."
"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."
Just one more example of why I think Firefox is a terrible browser on OS X. Platform conventions exist for a reason, and violating them should not be done without extremely good reason.
[Removed because I accidentally pasted a link to hackerne.ws rather than news.ycombinator.com, since someone already posted the real link in reply, I'll just remove this]
Link to actual hacker news: http://news.ycombinator.com/item?id=2948394
I'd call it a feature, not a bug
""" 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.