Closed Bug 38415 Opened 25 years ago Closed 14 years ago

Insert to toggle typeover mode in textboxes/textareas

Categories

(Core :: DOM: Editor, enhancement, P3)

Product:
Core
Component:
DOM: Editor
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: bugzilla, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: helpwanted, ux-mode-error)

Build ID: 2000050608 I realize this isn't the most useful feature in the world, so if this isn't easy to implement, feel free to mark WONTFIX. I just now noticed [a little documented feature?] in IE 5.5 that hitting Insert will toggle typeover mode on/off in all textboxes and textareas. NS 4.x doesn't, and as of now, Moz doesn't either. Mozilla could include this, and expand on the idea by perhaps some kind of visual indicator somewhere [taskbar?] that it's on. OK, in hindsight, screw the indicator idea - a small feature like typeover doesn't justify any space in the status bar, no matter the size. How hard would this be to implement?
enhancement request -- setting to M20
Target Milestone: --- → M20
Status: NEW → ASSIGNED
Target Milestone: M20 → Future
Assignee: beppe → nobody
Status: ASSIGNED → NEW
see bug 65115
OS: Windows 98 → All
Hardware: PC → All
You *just noticed* this IE feature? I accidentally hit the insert key about once a week. A new Windows user who isn't familiar with the insert/overstrike modes probably gets very confused when he first encounters this behavior, especially since neither the screen nor the keyboard gives a visual indication of the mode (unless you're using MSWord). Recommend wontfix.
For some reason the addressbar doesn't count as a textbox in IE6. kinda odd. -- It's the place i'm more likely to want to use it (w98se)
Ditto the wontfix suggestion. Non-obvious modes tend to suck, and I regularly get bitten by this one in MSIE.
Summary: [RFE] Insert toggles typeover mode in textboxes/textareas → Insert toggles typeover mode in textboxes/textareas
No longer blocks: 65115
*** Bug 65115 has been marked as a duplicate of this bug. ***
*** Bug 94529 has been marked as a duplicate of this bug. ***
Has it occurred to *any* of you that we can draw a "box" cursor to indicate typeover? That would prevent the only valid objection I've seen to this bug being fixed.
To elaborate further, the current cursor looks like this: A|BC An overtype cursor would look like this: A[B]C (B alternates between normal and reversed colors) Overtype isn't very useful for ordinary textboxes and message boards, but it's an important thing to have in any serious editing tool (including online editors that use HTML forms). It should be harmless to implement and beneficial to the function of Mozilla.
Keywords: helpwanted
Just one user's comment here: in the address bar, insert mode wants to be the default, but it is *very* handy at times to be able to toggle to overwrite mode, which is traditionally shown, as has been noted, by a box or shading cursor, which is easy to notice. This doesn't exactly make or break a browser, but it seems a pretty useful thing. I have many and many a time cursed at the inability to simply overtype a character or three to make a new target URL.
Using a different cursor doesn't make it obvious how to get back to "normal" mode, and it doesn't change the fact that most users press Insert accidentally much more often than they hit it intentionally. I still recommend wontfix.
FWIW, neither Notepad nor Opera has this feature.
Summary: Insert toggles typeover mode in textboxes/textareas → Insert to toggle typeover mode in textboxes/textareas
*** Bug 211060 has been marked as a duplicate of this bug. ***
*** Bug 211878 has been marked as a duplicate of this bug. ***
Opera has had this feature for a long time already. Why doesn't Mozilla? Is this usually how it goes? Somebody brings forward some weird argument why a feature is bad, everybody disagrees to the argument and wants to see the feature implemented, and then the bug just sits unresolved for ages or gets WONTFIXed? 4 people have opened duplicate bugs, doesn't that say something? ;-)
Blocks: 192458
*** Bug 262400 has been marked as a duplicate of this bug. ***
If there's an 'insert' button on my keyboard - how could this bug be wontfix? Are you saying, that pressing pgdown by accident and continuing to write at the wrong position is the browsers fault? If someone could point out where this is handled in the code, I'd be glad see if I can patch it. - Even if it's only for my build - my customer, who uses mozilla company wide - need this functionality, as they're in the news business.
(In reply to comment #17) > If someone could point out where this is handled in the code, I'd be glad see if Found.
(In reply to comment #17) > I'd be glad see if I can patch it. Got a patch for 1.7.2 ready here, which should apply to 1.7.3 too. If someone's interested, drop me a note. (It's per field atm, so I won't attach it here - wouldn't be integrated anyway.)
*** Bug 272967 has been marked as a duplicate of this bug. ***
Blocks: 266665
*** Bug 293878 has been marked as a duplicate of this bug. ***
No longer blocks: 266665
*** Bug 266665 has been marked as a duplicate of this bug. ***
I can't believe this Bug is 5 years old and it has never been fixed, or at the very least properly addressed. There's a key on my keyboard that says 'Insert'. Just becasuse Notepad doesn't allow the use of the Insert key, doesn't mean that it's something Firefox or Thunderbird users wouldn't *not* expect to see. That's right - Firefox AND Thunderbird (so pretty safe to say "Mozilla products"?) don't implement the Insert key function. Shouldn't Mozilla be encouraging users to 'make the switch' from other competing products by offering essentially the same functionality that they're used to .. and of course - improving on those features and adding more? The majority of Windows platform users will be used to Internet Explorer, Outlook Express, or Outlook - all which allow use of the Insert key. I am complaining rather loudly because this is not by any means the only 'feature' that is 'surprisingly' missing. The doors are open .. wide open for other apps to mimic TB & Firefox - and include everything that Mozilla *should* have addressed & included. (ex: A post above indicates that Opera allows use of the Insert key). And if that weren't enough, Microsoft is going to be launching Windows Vista, a new version of Internet Explorer featuring Tabbed browsing, AND totally updating Outlook Express with a 'new' app called Microsoft Mail - which will be chock-full of fantastic new email & newsgroup features that will put TB to shame. It's sad - I *want* to like Thunderbird, but there's so many things that are but just shouldn't be. At least Firefox's plus-side far out-weighs it's negatives..
It is deeply sad that RenegadeX isn't here to see any response to his/her spam. (Try new Microsoft Mail! More annoying non-obvious modes than Thunderbird!) But Mr/Ms X accidentally brings up a good point: the key is labelled "Insert". It is not labelled "Overtype Lock", as one would expect from the other keys on PC keyboards that trigger stupid modes (Caps Lock, Num Lock, Scroll Lock). So if the key does anything in Mozilla products, it should be Inserting something. Perhaps it could be used as a shortcut key for auto-filling forms.
(In reply to comment #24) Nice attitude.. I guess the world revolves around you - *you* don't have a need for the Insert key and therefore you assume that the rest of the world has the same attitude. It is on my keyboard, and though I don't use it often, I would like it to work in the programs that I use most. That's not too much to ask. Rather than give attitude, might I suggest a FIX (that another user, who happens not to like the Insert key, but understands & sympathizes with my point of view) -- put in the Options: "Enable Insert key functionality for overtype/insert modes - ON/OFF". Problem solved. I'm happy. You're happy. Instead, I'm not happy, you think I'm a 'spammer' and I think you're a jerk. Fantastic. :-[
I think that this is not a easy work. Because we need to control Undo/Redo transactions for new overwriting mode. Please don't write spam comment that is your demand. Here is not a forum. Here is a BTS that is a tool for developers, so here is not a tool for users. If you want to fix it, you should create and attach the patch for fixing this.
Part of bug tracking is deciding what's a bug and what isn't a bug. Attaching a patch wouldn't solve that.
I can't believe someone's actually started to philosophise about the labelling of the "Insert" key and that the functionality we're looking for should be called "Overtype Lock". This is completely irrelevant; the "Insert" key behaves like an overtype-lock key in all major applications except Mozilla, and most users who use that key at all expect it to work that way. The alternative feature you suggested is even worse: Absolutely no software in the world uses the Insert key for auto-filling forms! That would be completely weird and contrary to expectation. What you said is kind of like saying "Radio buttons shouldn't be for selecting options. Since they're called radio buttons, we should use them to allow the user to select a radio station to listen to."
Just wanted to add 2 things: - I downloaded Opera and its implementation is EXCELLENT. I say 'excellent' because it is even better than in Internet Explorer. Opera allows insert/overtype in *any* text area - address bar, toolbar search box, all webpage text entry areas, and all email/newsgroup Compose windows - even the newsgroup Subscribe search box. It also (better than IE again) allows for Undo/Redo in all areas. - Interestingly, Opera uses a | for it's regular insertion point and a ▌ (unicode U+285C 'Left Half Block') character for its overtype indicator *in mail Compose* text-area only. All other components & text areas (including mail To:, Subject: text areas), there is no change in the indicator from mode to mode.
At least it should be added to be compatible to other browsers. A user found following: IE (Windows): Insert works Opera (Windows): Insert works Firefox (Windows): Insert does not work Konqueror (Linux): Insert works See the discussion here: http://forums.mozillazine.org/viewtopic.php?t=436236
Timwi, your analogy is flawed because the term "radiobutton" rarely if ever appears in a UI; where controls have to be referred to at all (e.g. in help pages), they're best referred to by label rather than by type. But the "Insert" key is always labelled "Insert", regardless of what you make it do. Volkmar, "compatible" refers to interoperability. Implementing an overtype mode would not make Firefox or Thunderbird one whit more interoperable with other browsers, Web sites, or mail clients. And just to drop another anvil on RenegadeX's enthusiasm for future Microsoft products, Microsoft Office 2007 will disable the Insert key by default. <http://miksovsky.blogs.com/flowstate/2006/07/insert_key_safe.html>
QA Contact: sujay → editor
I feel like this is a silly argument. If you don't like the overtype mode just get rid of it on your computer. Otherwise, you're forcing your wants and desires on other people. Just because you don't use it doesn't mean that it's not a good feature. Oh yeah, I always hit "a" instead of "s", so can you make sure that "a" is disabled? Thanks. That said I want the insert key to do what the insert key does.
I am adding my support in the hopes this issue will stay active and that the Insert/Overstrike key will be enabled. Thanks.
I converted to Firefox today because of continuous problems encountered when using fkdeditor to edit & paste text to webpages - I duplicated all of the things that caused crashed in IE and when I tried Firefox and didn't have a single error! However, I use the insert/typeover toggle the most out of all of the keys on the keyboard - to fix errors (ie capitizations & incorrect punctuation) and am totally screwed without it - unless I can find a way without having to cut & paste to a text editor like Word all the time, I will have to go back to IE. I would seriously appreciate this function being supported in Firefox - the sooner the better!
As far as I can tell, the only argument brought forward against implementing this was that there is no visual feedback. I don't really see why it's so hard to provide visual feedback. You could have a small icon in the bottom-right corner of the textbox/textarea that says "OVERTYPE" or similar. It could even have an on-hover tooltip that explains that you can turn it off by pressing "Insert". Does this address the concerns or are there any others?
In response to the message regarding Microsoft Office. Yes, it is true that Office 2007 no longer uses the Insert key **by default**. But this is not important because Office 2007 retains the feature and allows you to customize all keyboard shortcuts. In Firefox the feature is entirely missing. That's quite a significant difference.
Hear Hear. I would like to see this implemented as well.
That's a standard editing-feature/behaviour "normal" users expect. I don't use it personally but customers complain about. Even in FF 4.0 this is still not supported. In times of html5 and webapp's it's absurd and sad that mozilla totally ignore this. Unbelievable ...
How do the rest of the current browser releases compare here? I'm interested in the results of only the following browsers: IE 9 Chrome 10 Safari 5 Opera 11
IE 8 and Opera 11 support this feature. Chrome 10 doesn't support this. IE 8 doesn't change visually. Opera 11 changes the caret width wider but not same as the width of overwritten character. If we support this bug, we should support wide caret first (the width should be same as the overwritten character width). Then, the feedback helps to let users know which mode has been activated. And also the feature is needed for Korean IME on Windows (see bug 489951). I think that nsTextFrame should draw caret itself. It should use the character's foreground color and background color as caret color and reverted character color. Then, we can draw it like XOR rendering. For other frames, nsCaret should draw caret itself.
IE 9 support this feature. Safari 5 doesn't support this. (Is there an insert-key on mac's? ;) ) Visualisation will be fine but isn't mandatory IMHO. (ie9 does not, opera does -> should be de reference implementation) Providing and supporting this functionality should be the primary focus.
(In reply to comment #41) > If we support this bug, we should support wide caret first (the width should be > same as the overwritten character width). Then, the feedback helps to let users > know which mode has been activated. Supporting wide carets is really easy. We can just set a flag on the caret, and modify nsCaret::UpdateCaretRects to generate a rectangle wider than 1px. I don't think that the caret functionality should be spread over to nsTextFrame. > And also the feature is needed for Korean IME on Windows (see bug 489951). I don't exactly understand what the relationship here is. But the main code change here is supporing the insertion mode. I guess you could modify the editor's keyboard handler to replace existing characters in the insert mode. If you're willing to work on this, I can give you a more precise idea of what needs to change roughly.
Keywords: uiwanted
(In reply to comment #43) > (In reply to comment #41) > > If we support this bug, we should support wide caret first (the width should be > > same as the overwritten character width). Then, the feedback helps to let users > > know which mode has been activated. > > Supporting wide carets is really easy. We can just set a flag on the caret, > and modify nsCaret::UpdateCaretRects to generate a rectangle wider than 1px. I > don't think that the caret functionality should be spread over to nsTextFrame. "wider" caret isn't good for CJK text because we already using wider caret if next character is a CJK character. See bug 335359. > > And also the feature is needed for Korean IME on Windows (see bug 489951). > > I don't exactly understand what the relationship here is. So, the character width caret is useful for IME implementation too. Sharable approach is better. And if we could implement it, we could remove the wider caret of bug 335359 because it guarantees caret is blinking on all cases. > But the main code change here is supporing the insertion mode. I guess you > could modify the editor's keyboard handler to replace existing characters in > the insert mode. If you're willing to work on this, I can give you a more > precise idea of what needs to change roughly. I'm working on implementing DOM3 key/composition/text events on all tire-1 platforms and some mouse wheel handling code improvement on Windows. Therefore, I don't have enough time for editor in this cycle...
Another possible idea is, we implement only the overwriting mode first but it's disabled by pref. If so, somebody who loves this feature can use this feature but most users aren't confused by the non-visually feedback.
(In reply to comment #44) > (In reply to comment #43) > > (In reply to comment #41) > > > If we support this bug, we should support wide caret first (the width should be > > > same as the overwritten character width). Then, the feedback helps to let users > > > know which mode has been activated. > > > > Supporting wide carets is really easy. We can just set a flag on the caret, > > and modify nsCaret::UpdateCaretRects to generate a rectangle wider than 1px. I > > don't think that the caret functionality should be spread over to nsTextFrame. > > "wider" caret isn't good for CJK text because we already using wider caret if > next character is a CJK character. See bug 335359. By wide, I meant a caret as wide as the character itself. I guess the caret should follow the platform conventions though. The CJK caret is something entirely different. (In reply to comment #45) > Another possible idea is, we implement only the overwriting mode first but it's > disabled by pref. If so, somebody who loves this feature can use this feature > but most users aren't confused by the non-visually feedback. Of course that's possible. Although this is pretty low on my list of things to do in the editor...
naive question: what do people gain by having type over mode? When I was much younger I would accidentally trigger it in word, and believing it was a bug, have to restart the application to reset the mode. That's not to say there isn't any benefit, I just for some reason can't think of it off the top of my head. Reduced interactions with text selection?
(In reply to comment #47) > naive question: what do people gain by having type over mode? Overwrite mode is useful because some people email you "forms" that are formatted for printing so they look (literally) like this: First Name: ___________________________ Last Name: _____________________ I request to meet with teacher __________________ for __________________ at ____________________ because I need [ ] extra credit [ ] remedial help (Schools seem particularly prone to this kind of thing.) With Insert Mode, your only option for returning a correctly formatted form is to type in your name and then delete as many occurences of the _ as you typed in. Frankly, it is a giant pain in the behind. In overwrite mode you can just bang away over the underscores without ending up in reformat hell. The reason people really want to see this in Firefox is because then we would (presumably) gain overwrite mode for Google Docs and other web-based editors. As Bernd said above, this is something that many "normal" users expect because most word processing software (not to mention unix editors) support it. While I understand the various objections (lack of visual indicator, confusion if accidentally turned on), all can be dealt with making this only available by going out of your way to activate it through an option.
While I generally want content editable to support all of the features of Word, this is kind of a rare case of a feature that I don't think should have been in Word to begin with. Similar to caps lock, the opportunity for mode errors and confusion across all users seems to outweigh the gained functionality for a smaller set of users. I understand the use case now, I just don't think it warrants introducing a modal interface. I'm concurring with 2001 Jesse in comment #3 and setting to wontfix.
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: uiwanted → ux-mode-error
Resolution: --- → WONTFIX
Hmm, I don't use the overwriting mode. But I think that "WONTFIX" isn't good decision for this bug because native textbox widget has this feature on Windows and GTK. If somebody wants to *implement* this feature, we shouldn't prevent the work.
I can't believe that such basic editing functionality that has been present on editors of all kinds and all operating systems for the 25 years I have been using computers was omitted in the first place. Nor can I believe that a "smaller set of users" would have misunderstood "Insert" or "Overwrite" being displayed in Word... especially when the key on the keyboard is so clearly marked "Insert"! Wontfix?? I'm stunned. Especially in corporate environments where nearly every productivity application seems to be migrating to the browser interface (not a trend I'm a fan of, but not something that can be reversed when words like "cloud" are so trendy), missing basic functionality like this starts to become a real pain. And as mentioned by others already, all the concerns about the mass confusion that could arise from implementing this feature would be resolved by making it an option that is off by default; even if it was only available for this "smaller set of users" under about:config or similar. Is this a feature that could be added through a plugin perhaps, or is it too close to the "core code" of firefox to override the input behaviour? I won't even start on caps lock.
Alex, I think that the UX mode error issue can be addressed with a correctly shaped caret. Don't we want this for platform compat at least?
The problem is that users don't realize that they entered the mode (usually insert is hit by accident, since the majority of users don't actually know what the key is for). So even if we very clearly surface the mode visually, it still gets parsed as a strange bug in Firefox, instead of an intentional behavior. >even if it was only available for this >"smaller set of users" under about:config or similar. We don't normally go to the work of landing features that are both off by default and hidden in about:config, but from a UX perspective that would of course be totally fine, as would an extension. I know wontfix seems harsh if this is a feature that you both understand and regularly use, but I really think typeover was a rather significant interface mistake that needs to be eventually corrected. I can't go back in time and convince the people working on desktop publishing era productivity software, or native OS controls, but I can strongly endorse it not showing up in future versions of Firefox.
This is NOT resolved, and THIS NEEDS FIXED! For goodness sake, rather than ignoring this necessary feature, time can just be spend EDUCATING people on the function of the INSERT key. I've scoured multiple search engines (Bing, Yahoo, MSN, Google, Ask), and COUNTLESS users are requesting that this be made a feature. I don't think this is too tall a demand. If my Firefox can be randomly and instantly be updated/upgraded/patched without my knowing it (such as how it went from Firefox 11 to Firefox 16 without me knowing), then I don't think it's impossible to make one SIMPLE bit of code work for the many users who USE Firefox, Develop AddOns for Firefox, and those who have donated to Mozilla to encourage it's growth.
(In reply to Blake Ross from comment #0) > Build ID: 2000050608 > > I realize this isn't the most useful feature in the world, so if this isn't > easy to implement, feel free to mark WONTFIX. > > I just now noticed [a little documented feature?] in IE 5.5 that hitting > Insert > will toggle typeover mode on/off in all textboxes and textareas. NS 4.x > doesn't, and as of now, Moz doesn't either. Mozilla could include this, and > expand on the idea by perhaps some kind of visual indicator somewhere > [taskbar?] that it's on. > > OK, in hindsight, screw the indicator idea - a small feature like typeover > doesn't justify any space in the status bar, no matter the size. > > How hard would this be to implement? Let's not suggest they add this to "WONTFIX". It's like writing a eulogy for a man still in his prime..... it's equivalent to a jinx lol
I just created an account and I find it an incredible shame that this ridiculous issue is the reason for my first post on the system. I really have to restrain myself not to insult anybody. I am literally upset. A vast majority seems to be in favour of the feature which, by the way, is way older than window-based operating system GUIs. The reason why the button is called "Insert" and not "typeover", by the way, is that typeover used to be the default mode back then, so "insert" instead of "typeover" would be the functionality that is toggled by the key. Everybody who does not know about the functionality of the key will learn this in basically no time. Every child is able to realize how it works. Come on, don't think the majority of people/users is so dumb. WONTFIX is a shame.

Overtype mode would be really useful when editing ASCII/Markdown tables, like these...

| foo | bar   | baz |
|-----|-------|-----|
| quz | quux  | zap |

I make a lot of these (e.g.) in issues on GitLab and other sites. Firefox support for overtype mode would make these tables easier to edit in-place, and avoid the need to transfer the text back and forth to a different editor.

Maybe overtype mode could be disabled by default (thus protecting unsuspecting folks from accidentally pressing the insert key), and enable-able in about:config?

You need to log in before you can comment on or make changes to this bug.