Closed Bug 21887 Opened 25 years ago Closed 25 years ago

Input fields/text areas have focus/blur issues

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Other
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: hyatt, Assigned: hyatt)

References

Details

The lazy instantiation of the input/textarea webshells is confusing the
event state manager's notion of focused/blurred elements.  This needs to be
fixed either with a hack or the lazy instantiation needs to go.

I want this addressed at Pork tomorrow.
Is there a hack that will tide us over until lightweight (native-widget-less and
docshell-based) text inputs arrive?  I'd hate to undo lazyness and see the bad
perf on ~20-input pages.

/be
Status: NEW → ASSIGNED
Target Milestone: M12
Yes, I have a hack I could check in, although I believe that shaver,
travis, and pav were all against it, which is why I want to discuss it
at pork.
I don't have it on my machine at home.  I think the issue travis, pav, and
shaver had is that they want to deliberately withhold adding hacks (even
small safe ones like this one) because they believe that it will cause the
fundamental issue (that the lazy instantiation is wrong) not to be addressed.

In case you can't tell, I disagree. :)
By waiting till 4pm today, we risk not fixing this in M12.

I'm here to tell you all that hyatt's hack is not going to paper over the need
for a better fix.  The porkjockey webshell work has often turned on questions of
text performance, ever since the horror of eager, heavyweight (both in terms of
native window overhead, and of old webshell overhead) webshell creation for each
text input on a page was upon us.

I think you should get your hack checked in ASAP, if it makes things better and
never worse, measured by code behavior.  I'll preapprove.

/be
We can even leave the bug open to track the fact that I need to remove the hack
at some later date.
I think it's right to add the hack, leave the bug open, and discuss the need for
lazy instantiation separately.
Recall, lazy instantiation is there because creating webshells in today's world
is unacceptably slow.  This was hurting initial layout of dialog UI's, as well
as initial layout of many important pages (like bugzilla).
If lightweight docshells fulfill their promise of quick loading, then we can
almost certainly turn off lazy instantiation.  But until that's in place, I
think it's a mistake to turn it off for M12, since there's a safe way for hyatt
to fix this problem.
I'll turn lazy instantiation off in my tree, and try to generate some real
performance numbers for comparison.  Could it be we're so fast now we don't need
it any more?
unscientific wall clock research:
1) pages/dialogs with 4 or less text controls perform approximately the same
with immediate or lazy instantiation.
2) pages with a moderate number, like an existing bug report, are definately
snappier with lazy instantiation, both initial loading and loading of the next
page (destroying all those webshells is very expensive, also, so this hurts our
performance changing pages regardless of the content of the subsequent page.)
3) pathological cases like
file:///S|/mozilla/dist/win32_d.obj/bin/res/samples/test8sca.html
perform unacceptably slow with immediate instantiation:  ~1 minute to load vs. 2
seconds.  Also ~1 minute to change pages  vs. no noticable lag.

This measures raw performance only on a powerful machine.  Slower machines will
degrade worse, due to VM thrashing since Our memory load is much greater with
immediate instantiation, but I don't have hard numbers to back that up.

I'm still in favor of hyatt's hack until we get lightweight docshells that
perform at the same order of magnitude as the lazy solution.
Lazy instantiation down the road is the wrong thing.  If we continue this path,
this isn't the only hack that has to go in.  Currently clicking on the field
before it is there causes a general drag, we must at some point hack that code
to have knowledge of the internal details of the implementation of input.  Then
who knows what else has to be hacked around for this one widget.

In the world where docshells are light weight enough to be performant for a
input fields great, but we also have to realize that they may not be performant
enough for input fields.  In that case they are the wrong tool for the job.

On the course of getting them more performant, I think the work that the paint
team has on their plate for removal of native widgets should greatly increase
the performance.  I still have yet to see a response from McCluskey asnwering
when this is landing or being checked in, but this may fix our problem enough
where we can ditch the lazy loading of webshells.  CCing those working on that.
Travis: many subsystems can be lazy without requiring internal details to be
known in other subsystems, or otherwise violating modularity.  If you have
interface methods such that a click can know not to start a general drag, by
calling down into the lazy code and forcing it to be eager, what's the problem?
What you write implies to me that we already have too many internal details
exposed to the event subsystem.  If so, we should fix that so we can make the
lazy/eager choice independently.

/be
brendan: I know systems can be lazy.  And I'm all for lazy instantiation.  But
the bug and problem at hand is that in order to do this there is a number of
pieces of code that are having to be hacked to know about the internal
implementation details of the input widget.  You write "What you write implies
to me that we already have too many internal details exposed to the event
subsystem.  If so, we should fix that so we can make the lazy/eager choice
independently."  to which I say, "Um, yes..  This is the topic we are arguing
about."  You last night approved the adding of the code for the event system to
have detailed knowledge about this controls implementation.  This same code you
approve you are now saying in philosophy needs to be removed?
just collided with be, but I'm saying the same thing.
The system design should be robust enough that private detail of an object like
whether the subdoc is created immediately or lazily should be transparent to the
outside world.
This is analogous to the tree widget's decsion to lazily create and eagerly
destroy frames based on visibility.  That work has exposed some weaknesses in
the layout system that  needed to be addressed, but that doesn't change the
validity of the approach.
So of course, neither buster nor I were arguing about what to do for M12.  We
both like the hack for M12; we have not reneged.  But for M13, can we not have
"modulary laziness?"

I added to this bug in reply to Travis cuz he seemed to argue that we can't be
lazy without hacking lots of places, period, full stop, ever and ever.  I may
have misunderstood (sorry if so), but I thought he was talking about the long
run, not the M12 hack-space we're trying to get out of.

/be
final m12 candidates are spinnning now. moving to m13.
if we fall off track and need to respin m12 for some
yet unknown reason we can consider this if you get
a fix in hand.
Blocks: 8014
*** Bug 21406 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Closing this.  Will let specific bugs speak for themselves.
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
please ignore, massive spam giving jrgm@netscape.com backlog of XPToolkits
resolved fixed bugs to verify
QA Contact: paulmac → jrgm
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.