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)

PowerPC
macOS
defect
Not set
major

Tracking

(Not tracked)

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.