Closed Bug 148098 Opened 23 years ago Closed 19 years ago

Switch to native text widget for HTML text fields

Categories

(Camino Graveyard :: HTML Form Controls, defect)

Product:
Camino Graveyard
Component:
HTML Form Controls
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: jeff, Assigned: mikepinkerton)

References

Details

One very glaring problem in chimera right now is the text feilds in HTML forms. When typing in text feilds it can not keep up with someone of only moderate typing speed. The problem seems to get worse when there is more text in a feild. This bug has been apparent since quartz was introduced, thus leading me to beleive the problem lies there. Although this isn't a crasher or anything I filed it as major because it really affects the usability of the app, especially for those who do a lot of text editing in the browser.
Component: Page Layout → General
->brade, any thoughts
Assignee: saari → brade
I personally think we should implement native text fields (just as we did with scrollbars). Then we could also dump the entire editor dylib and make the download even smaller.
This would also eliminate the litany of text field bugs, wouldn't it? bug 108120 bug 108125 bug 16203 Might it also provide for the simple implementation of spell-checking? Comment 2 seems like it would be a big improvement.
Status: NEW → ASSIGNED
Summary: HTML text feilds need optimization → HTML text fields need optimization
I am pretty sure that with very little work spell checking is available to all Cocoa NSTextViews.
*** Bug 153417 has been marked as a duplicate of this bug. ***
-->Future for now; this won't be a trivial task like scrollbars we have to worry about commands and other things that make this a bit more messy
Keywords: helpwanted
Summary: HTML text fields need optimization → HTML text fields need optimization (native text widget)
Target Milestone: --- → Future
Short of replacing text entry fields with native controls, one optimization you could do would be to have it not invalidate the entire text entry region (it paints the whole thing for every character you type - this is slow). Typical behavior is to limit repainting to the current line. I noticed this after reading 151344 - "poor javascript & rollover performance" and breaking out Quartz Debug (comes with the OS X developer tools) to see if this was part of the text entry problem. You can see other weird stuff going on with Chimera with QD running, but those aren't relevant to this bug. The text entry field also has an "appears on-demand, with text reflow" scroll bar rather than the normal disabled scrollbar thing. I don't know, probably a UI issue but reflowing text is slower than not doing it so it has to have some impact :). Last but not least is deleting text with the delete key. This is the slowest aspect of text entry and you can often see an extra cursor at the left margin of the box while holding the key down - something strange is obviously going on here.
Would also help bug 151110 since NSTextView already implements NSTextInput. AFAIU, the only drawback (besides the required work of course) for this change is that some CSS functionality is broken. However, compared to the many many things this would fix (not to mention that we would behave exacty like other Cocoa apps regarding text input), this is a minor loss. Esp. since I haven't actually ever seen a page that tries to layer stuff over a text field (I am curious, can somebody point me to an example URL?)
Here are some of the bugs that ericlob@cris.com pointed out earlier: Bug 151682: ResizeView() invalidates too much when typing in a text widget Bug 151882: Pressing backspace in a text field makes the cursor flash in the beginning of the field Bug 151882 was actually a regression caused by me when I landed the perf fixes for bug 141900 ... specifically, the changes that made text widgets use async reflow and paints. The problem is that the caret is shown/hidden in several places (editor, layout, etc) several times *synchronously* and at times the frame data it uses to draw our out of sync because the reflow hasn't happend. I've started trying to rework the caret hiding/drawing code as part of bug 54153, but I've been sidetracked by other bugs. I've mentioned to both sfraser and brade that my text widget async reflow/paint perf changes can be disabled by simply commenting out the line in mozilla/layout/html/forms/src/TextControlFrame.cpp (formerly nsGfxTextControlFrame2.cpp) that adds the eEditorUseAsyncUpdatesMask to editorFlags.
*** Bug 167020 has been marked as a duplicate of this bug. ***
Reassigning to HTML Form Controls.
Assignee: brade → bryner
Status: ASSIGNED → NEW
Component: General → HTML Form Controls
kathy, feel free to reassign if needed...
Assignee: bryner → brade
keeping brade on the cc list after the component change.
Has any progress been made recently on this bug? I hate to include opinion in here for fear of starting a disscussion that would belong somewhere else (mailing list, etc.) but I think that it isn't a good idea to target this as future. This is currently one of the big usability problems with Chimera, and fixing it should not be put off and regarded as a low priority. I don't want to have a discussion on here I just want to get an idea from the developers on how big a bug they regard this as.
To Jeff and all other who think this should be higher priority, one of the best things you can do to increase its priority is voting for it. Droping my ballot.
*** Bug 172519 has been marked as a duplicate of this bug. ***
I've voted too.. this one is a real pain for me.. if I reply to an email, and the original quoted message contains even a moderate amount of markup, the response can be irritatingly slow - and gets slower as more and more input is entered in the reply. Even if I start a new message, after about 15k of text, things slow enough to notice. I see someone mentioned it happens because the entire contents of the text box is invalidated on change, and must be fully redrawn, even if it is offscreen. This approach is always going to result in performance issues, so something really does need to be done about it. Incidently, this occurs on an AMD 2100+XP athlon with 512mb of ram.. hardly a slow system.
Ian Batterbee--I think you are mistaking. This is for Chimera. Did you port OSX and Cocoa or something? :-)
Well, the Gecko text widget sort of sucks on all Mozilla variants on all platforms, so it wasn't that far off topic.
Oh... so it is.. oops. Although it's still valid.. heh.. Anyone know the bugid for this bug for the main mozilla stream ? If they fix it there, it should fix it in all varients.
I suspect that you are talking about the multi-line INPUT controls, like the one for "Additional Comments" on this page. But the single-line inputs (of type="text", or default) are also non-standard. Normally on the Mac when you tab from one text field to another any text that is already in the field gets highlighted (try the "print" sheet, for instance). But in Mozilla/Chimera, it inserts the cursor at the end of any existing text instead. This often messes me up when I start typing and expect it to replace what is in the field, but Chimera appends it to the end of what is there instead.
*** Bug 179244 has been marked as a duplicate of this bug. ***
*** Bug 169066 has been marked as a duplicate of this bug. ***
How many votes does it take to implement?
it's not about votes; it's about code... someone needs to step up and write the code (or hire someone who can?)
brade in comment #6 you mention commands can you provide more details about what makes this tricky? (not that I don't believe you...)
Blocks: 147975
I believe the textarea performance has improved significantly on trunk builds. Can anyone confirm? Of course, the textareas are still ugly gecko html widgets. (We'd all prefer they looked like proper cocoa text fields that would underline our misspelled words and work with the services menu, etc.) But as far as "optimization" goes, we could probably close this bug.
If this bug is closed, then I think the parenthetical in the Summary should become its own bug.
Closing this bug would be throwing out 85 votes, of which the majority I'd wager are registered with regard to the "native text widget" aspect.
So perhaps the summary should just be changed then? But the text field speed may regress once the pseudo-native controls from Chimera are landed on the trunk.. (see bug 188254)
The text entry speed has gotten a lot better lately so I have removed my vote for this bug.
I second the motion to change this report's description to simply read "Replacement: native text widget for HTML forms" or something of that nature. Not that I have any meaningful clout...
Changed title. (Was: HTML text fields need optimization (native text widget))
Summary: HTML text fields need optimization (native text widget) → Switch to native text widget for HTML text fields
From a purely aesthetic standpoint, this has gotten worse since moving to the trunk. Whereas in the past, single- and multi-line text input fields would at least look like proper Aqua widgets, they now appear comparatively harsh. For practical purposes, the bottom- and right-side boundaries of text entry fields are invisible; the top- and left-side shadow is too dark. If nothing else, they should be polished to better fit in with their Aqua neighbors. Camino nightly 2003031808 on 10.2.4. I suppose this bug now applies to the mainline Browser component as well? Mark
This is Camino only. There is barely the lightest of gray lines on the right/bot edge of text fields at the moment.
I don't really care if real Cocoa text fields are used in Camino (although it was nice), but one behavior which was introduced recently should urgently be fixed: Camino displays the background of a text field in the colour of the surrounding area. This makes some text fields unreadable on dark backgrounds, since the font colour is still black. (If this can somehow be influenced by some setting: please tell me!) For examples, check the search text field on http://www.versiontracker.com or the search field on the left hand side of http://www.areadvd.com/
Blocks: majorbugs
I might take a look at this, I've been looking for a holiday project. I don't know how crufty the textarea code is, though, so I'm not promising anything!
:) please do
This is potentially relevant: Hosting cocoa widgets inside carbon windows. http://tinyurl.com/ywmau (because nobody will tell me how to mark up a link in Bugzilla without embarassing myself) -reg
Also, assuming that the above doesn't pan out, we could at least upgrade text fields to the modern HITextView and fake spell-checking with Richard Buckle's ingenious bridge: http://www.sailmaker.co.uk/progtools.html#spelling -reg
a cocoa text view would work fine (we don't need any weird bridges or carbon widgets), the work comes with making it reflect all the dom attributes and javascript behavior hooks.
Assignee: brade → pinkerton
QA Contact: winnie
Is there any movement on this old, old bug? I've still got achingly slow text repaint on text fields, particularly gmail's when there is a lot of text in the box. The cursor blinks "wrongly" when typing, somehow, and there's no for-free spell checking. It's a major camino deal-breaker here.
Most of that is bug 272954 which has nothing to do with this directly, and spellchecking is bug 151040. This is mostly an implementation detail.
i believe the webkit team is moving away from native widgets entirely (they're too slow) so we probably don't want to introduce them ourselves.
I hope this is the right bug. I've been told so. I visit so many forums based on phpBB that this has become a "use breaker". Regardless of whether other tabs or open or whether there are animated gifs, i can no longer use Camino when in a forum i could probably type a couple paragraphs by the time one word shows up.
(In reply to comment #46) > I hope this is the right bug. I've been told so. > > Regardless of whether other tabs or open or whether there are animated gifs, i > can no longer use Camino when in a forum i could probably type a couple > paragraphs by the time one word shows up. Actually, that's bug 272954.
Considering this bug is hitting its 3 year anniversary and to me is a crucial bug as it is almost impossible to write something in a text bug. Heck I have to wait for it to catch up for me as it lags behind 3-4 sentences. This is why I am writing this up in Safari, not Camino.
Yvo van Doorn: that is bug 272954 and has nothing to do with this bug. Please do not comment in this bug about slow text fields.
No longer blocks: majorbugs
As Mike said in comment 45, Safari is moving away from native widgets and I don't think we should go that route either. Should this bug be WONTFIXed?
I don't think I'm the only person for whom WONTFIX on this serious flaw would clarify the position of WONTUSE on Camino. Isn't the entire purpose of the Camino project to wrap native UI conventions around Gecko? This seems like a clear and worthwhile goal, and I cannot imagine why something so fundamental as text fields would merit an exception. If we wanted nonstandard, application-level widgets, we'd be using Firefox. I'm surprised by the suggestion that native widgets are "too slow"; I have never perceived any slowness whatever in standard osx text fields--quite as opposed to the experience with Camino. More importantly, this would in one fell swoop solve all of the other issues relating to standard system spellchecking, in-field keybindings, selection after tabbing, and so on. And it would solve them in the right way: not by reimplementing the whole shebang yourself, but simply using the native tool that's sitting there begging to do all of the work. L. H., given that text field performance (which is very much unresolved, despite what bug 272954 claims) is just one of many aspects of the choice to use native text widgets, I can't help but feel that commenting upon it in this bug is precisely appropriate.
This is not a flaw. It is an implementation detail. Anything that is wrong with text field behaviors is its own bug. Other controls in Camino are not native but look and act native and that is enough. WebKit is changing to controls that are not native for CSS compatibility and for speed. They have said so on their blog. Unless you know more about creating a browser with native controls and the speed and compatibility issues it has than the WebKit team please do not comment about what the right way to implement this is. Native controls would mean reimplementing all the CSS that works now and losing some CSS compatibility so there is reimplementation either way. The place to comment about problems with text fields is in bugs about those problems. This is only about implementation. Only the developers understand enough to make a good decision about implementation so only the developers should comment about fixing this or not.
I spoke with Mike and this bug is definitely a WONTFIX. Camino does not intend to use native form widgets in the content area. Native form widgets are slower than our home-grown widgets and any advantages they may have can be duplicated in our widgets with some work. All other work to improve our widgets will be done in other bugs so please don't reopen this bug.
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: helpwanted
Resolution: --- → WONTFIX
Target Milestone: Future → ---
To follow up on what Sam said.... 1) Spellcheck work for Camino is already well underway. 2) If there are missing keybindings or editing behaviors in textareas, a) first check in a trunk build, as there have been many binding/behavior fixes that are only on the trunk, then b) search for existing bugs in the "Core" product ("Editor" and "Selection" are the two most likley components, for narrowing your search), and c) if you can't find an existing bug, file the new bug (one keybinding/behavior per bug) against the Core product and appropriate component (you can cc Sam or I so we can keep track of the bug, if you wish). Thanks. V. WONTFIX.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.