35299 - textfield inside menupopup does not behave, causes crash [@ nsView::GetDimensions ]

Status: RESOLVED FIXED

(Core :: Web Painting, enhancement, P5)

Description

[shalabh]

Build:    Pulled from cvs 10-Apr-2000

Textfield widgets placed inside a menupopup don't handle events properly. For 
both single and multiline textfields - they render correctly but text cannot be 
entered into them.

Reproducible: Always

Comment 1

[shalabh]

Attachment: tests\content\default\Test35299.xul

Comment 2

[shalabh]

Steps to Reproduce:
1. Download and save attachment as chrome/tests/content/default/Test35299.xul
2. Launch mozilla and point to chrome://tests/content/Test35299.xul
3. Two buttons appear. 
4. Click on any button - a textfield inside a menupopup appears.
5. Click on the textfield and try to enter some text.

Actual Result:
For single line: Shows cursor but typing doesn't enter any text.
For multi line: Clicking on the textfield causes flickering of mozilla 
titlebar. Typing doesn't enter text.

Expected Result:
Text should get entered into the textfield.

Comment 3

[shalabh]

Adding zopestudio keyword (Forgot earlier - my bad)

Comment 4

[Blake Ross]

When clicking inside the textbox of the menupopup of the first button, I got 
the following GPF (under 2000041008):

MOZILLA caused a stack fault in module KERNEL32.DLL at 0167:bff7429f.
Registers:
EAX=8175aaa4 CS=0167 EIP=bff7429f EFLGS=00000283
EBX=0059ff10 SS=016f ESP=00599d08 EBP=00008d00
ECX=c16881a0 DS=016f ESI=00a11bd0 FS=120f
EDX=000163a4 ES=016f EDI=bff5ffff GS=0000
Bytes at CS:EIP:
eb 95 8b 54 24 04 50 e8 04 00 00 00 58 c2 04 00 
Stack dump:
bff71547 bff555a7 00007dc4 0000000d 00599d4c 60ad54e7 00000ca8 ffffffeb 
00000000 00000006 00599d54 00007dc4 00599da0 7d5e03e7 0327180c 00000008 

Clicking inside the textbox in the popup from the second button produced this 
GPF:

MOZILLA caused a stack fault in module KERNEL32.DLL at 0167:bff7429f.
Registers:
EAX=817706f4 CS=0167 EIP=bff7429f EFLGS=00000283
EBX=0059ff10 SS=016f ESP=0059a03c EBP=00008034
ECX=c1537e30 DS=016f ESI=00a11bd0 FS=0d8f
EDX=000163a4 ES=016f EDI=bff5ffff GS=0000
Bytes at CS:EIP:
eb 95 8b 54 24 04 50 e8 04 00 00 00 58 c2 04 00 
Stack dump:
bff71547 bff555a7 000080f8 0000000d 0059a080 60ad54e7 000007f0 ffffffeb 
00000000 00000006 0059a088 000080f8 0059a0d4 809803e7 0327178f 00920008 

In both cases, the Mozilla titlebar flickered for a couple seconds (as focus 
seemingly passed from it to the textfield?) as you said before I got these 
GPF's.

Comment 5

[Peter Trudelle]

I crash typing in this field using today's NS6 verification build on Win98.
Reassigning to saari, cc hyatt & beppe

Comment 6

[Blake Ross]

do you need to type in the field to induce the crash?  All I have to do is set 
focus to either field, both produce two different (but similar) GPF's (as I 
said earlier).  This is strange since the original reporter didn't even mention 
a crash, just some abnormal typing behavior.

changing severity to critical [crash], adding kw and updating summary to better 
reflect bug

Comment 7

[saari (gone)]

A textfield inside a menu popup?!? I'm not going to entertain this until way, way 

later.

Comment 8

[Peter Trudelle]

Mass-moving all M20-M30 XPToolkit bugs to Future

Comment 9

[Asa Dotzler [:asa]]

Attachment: attachment of talkback stack trace requested by ksosez

Comment 10

[Blake Ross]

-> Views, cc'ing roc

Comment 11

[[e-mail]]

See also bug 94713.

Comment 12

[rubydoo123]

removing myself from the cc list

Comment 13

[Kevin McCluskey (gone)]

*** Bug 126090 has been marked as a duplicate of this bug. ***

Comment 14

[Robert Ginda]

Bug 126090 has patches to avoid the crash, but the textbox still has focus issues.

Comment 15

[Daniel Wang]

re comment #7

textfield inside popup might be un-usaul but could be useful for
housing a long string of text where space is limited. For example,
in the Preference dialog, the input line for home page url is too
short for some people; without resizing the dialog box, we could
put on the right edge of the input a [v] button which would popup
a two-line high text field upon clicking.
  _____________________________
 | long long long long long.|v|
 ``````````````````````````````
       |
      \|/
       `
  _____________________________
 | long long long long long lo|
 | ng long long url           |
 ``````````````````````````````

Comment 16

[Nigel McFarlane]

Status change due?  Textarea no longer visibly renders
inside a popup using the test case (Moz 1.01).

A more open question is: when did we lose the ability to
(even partially) arbitrarily contain UI elments within
other elements, and is this desireable?

Admittedly there is no stated design goal to support this
generality but to erode the existing possibilities away
accidentally seems an unfortunate consequence of non-design.

Useability is up to the document creator, not the
implementor of low-level UI elements, so there's at best a weak
argument for a "useability-qualified core" of UI elements,
at least.

At least the test case doesn't cause a crash now.

Comment 17

[Ariel Fatecha]

this is like bug 107520 which cause crash, textbox in scrollbox.

Comment 18

[Kevin Berkheiser]

I don't pretend to understand how xul works or how mozilla loads chrome links. 
But, I don't think the procedure in #2 works in Mozilla 1.7b.  I suspect
something changed in how xul and chrome work since this old bug was created.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316

Comment 19

[Asa Dotzler [:asa]]

this testcase seems no good. 

Comment 20

[Roland]

Attachment: testcase demonstrating textbox in a popup crashing mozilla.

I attached a very simple testcase with a XUL document that shows how a textbox
element in a popup crashes mozilla.

to reproduce the crash:
1) open this attachment in any Gecko browser supporting XUL (Mozilla 1.7 or
Firefox 0.8 will do fine)
2) click on any of the buttons except first to see how popups are generally not
causing craches
3) click on the first button for a crash.

Oh, and yes - my OS is WinNT 4.0 SP6, if that helps.

Comment 21

[Roland]

(In reply to comment #16)
> A more open question is: when did we lose the ability to
> (even partially) arbitrarily contain UI elments within
> other elements, and is this desireable?
No - it is absolutely not desirable...


> Useability is up to the document creator, not the implementor
> of low-level UI elements, so there's at best a weak argument
> for a "useability-qualified core" of UI elements, at least.
Could not have agreed more - as it is, a small pet-project of mine is currently
waiting for this bug to get fixed, so I could offer extremely light-weight data
entry dialogue for my application.  I'd try to fix this myself, only my employer
has been keeping me busy with enough work to keep me programming 'till Judgement Day


> At least the test case doesn't cause a crash now.
Well - I attached a new testcase that should cause crash for a textbox in a popup.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No-one is arguing that this is not a bug. So don't worry about that.

I'll take it on.

Comment 23

[Samuel Sieb]

I've been poking through a core file on Linux and this is what I got:

#3  <signal handler called>
#4  0x00f96d69 in nsRect (this=0xfee74aa0, aRect=@0x2c) at nsRect.h:57
#5  0x0134eb30 in nsView::GetDimensions (this=0x0) at nsView.h:248
#6  0x0134e844 in nsView::GetClippedRect (this=0x0) at nsView.cpp:840
#7  0x01354f07 in nsViewManager::UpdateView (this=0xa5f90a0, aView=0x0,
    aRect=@0xfee74b00, aUpdateFlags=4) at nsViewManager.cpp:1733
#8  0x01356e50 in nsViewManager::MoveViewTo (this=0xa5f90a0, aView=0xa462e78,
    aX=165, aY=810) at nsViewManager.cpp:2561
#9  0x00faeea4 in nsContainerFrame::PositionFrameView (aPresContext=0xa5f8a60,
    aKidFrame=0x9e4c0a8) at nsContainerFrame.cpp:481
#10 0x00fafe80 in nsContainerFrame::PositionChildViews (
    aPresContext=0xa5f8a60, aFrame=0x9e4c010) at nsContainerFrame.cpp:990
#11 0x00fafe94 in nsContainerFrame::PositionChildViews (
    aPresContext=0xa5f8a60, aFrame=0xa60a800) at nsContainerFrame.cpp:992
#12 0x00fafe94 in nsContainerFrame::PositionChildViews (
    aPresContext=0xa5f8a60, aFrame=0xa60a730) at nsContainerFrame.cpp:992
#13 0x00fafe94 in nsContainerFrame::PositionChildViews (
    aPresContext=0xa5f8a60, aFrame=0xa60a660) at nsContainerFrame.cpp:992
#14 0x010b82dc in nsBox::SetBounds (this=0xa60a694, aState=@0xfee757f0,
aRect=@0xfee74d20) at nsBox.cpp:585
#15 0x010c609f in nsSprocketLayout::Layout (this=0x9ac4288, aBox=0xa60a588,
    aState=@0xfee757f0) at nsSprocketLayout.cpp:483
#16 0x010c4eaf in nsContainerBox::DoLayout (this=0xa60a588, aState=@0xfee757f0)
    at nsContainerBox.cpp:610
#17 0x010bd991 in nsBoxFrame::DoLayout (this=0xa60a554, aState=@0xfee757f0)
    at nsBoxFrame.cpp:1052
#18 0x010b9070 in nsBox::Layout (this=0xa60a588, aState=@0xfee757f0)
    at nsBox.cpp:992
#19 0x010b498f in nsScrollBoxFrame::DoLayout (this=0xa60a460,
    aState=@0xfee757f0) at nsScrollBoxFrame.cpp:335
#20 0x010b9070 in nsBox::Layout (this=0xa60a494, aState=@0xfee757f0)
    at nsBox.cpp:992
#21 0x010c61d3 in nsSprocketLayout::Layout (this=0x9ac4288, aBox=0xa609ffc,
    aState=@0xfee757f0) at nsSprocketLayout.cpp:515
#22 0x010c4eaf in nsContainerBox::DoLayout (this=0xa609ffc, aState=@0xfee757f0)
    at nsContainerBox.cpp:610
#23 0x010bd991 in nsBoxFrame::DoLayout (this=0xa609fc8, aState=@0xfee757f0)
    at nsBoxFrame.cpp:1052
#24 0x010b9070 in nsBox::Layout (this=0xa609ffc, aState=@0xfee757f0)
    at nsBox.cpp:992
#25 0x010c61d3 in nsSprocketLayout::Layout (this=0x9ac4288, aBox=0xa609e50,
    aState=@0xfee757f0) at nsSprocketLayout.cpp:515

This is where the problem shows up:
#8  0x01356e50 in nsViewManager::MoveViewTo (this=0xa5f90a0, aView=0xa462e78,
    aX=165, aY=810) at nsViewManager.cpp:2561
2561          UpdateView(parentView, oldArea, NS_VMREFRESH_NO_SYNC);
(gdb) print *aView
$4 = {<nsIView_base> = {<nsISupports> = {
      _vptr.nsISupports = 0x148bf48}, <No data fields>},
  mViewManager = 0xa5f90a0, mParent = 0x0, mWindow = 0x0, mNextSibling = 0x0,
  mFirstChild = 0xa034b88, mClientData = 0x9e4c0a8, mZIndex = 0,
  mVis = nsViewVisibility_kShow, mPosX = 165, mPosY = 810, mDimBounds = {
    x = 165, y = 810, width = 0, height = 0}, mOpacity = 1, mVFlags = 612}
(gdb) print *view
$5 = {<nsIView> = {<nsIView_base> = {<nsISupports> = {
        _vptr.nsISupports = 0x148bf48}, <No data fields>},
    mViewManager = 0xa5f90a0, mParent = 0x0, mWindow = 0x0,
    mNextSibling = 0x0, mFirstChild = 0xa034b88, mClientData = 0x9e4c0a8,
    mZIndex = 0, mVis = nsViewVisibility_kShow, mPosX = 165, mPosY = 810,
    mDimBounds = {x = 165, y = 810, width = 0, height = 0}, mOpacity = 1,
    mVFlags = 612}, mZParent = 0x0, mClipRect = 0x0, mDirtyRegion = 0x0,
  mChildRemoved = 0 '\0'}

Note that the view has no parent!  This makes the next steps blow up.  I have no
idea how to find out whose view this is.  The mClientData field may have some
info if I could figure out what to cast it to.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It's probably bad view construction in nsCSSFrameConstructor.

Comment 25

[Roland]

Hey - there seem to be many bugs related to the same problem: bug 107518, bug
165469, bug 151826, bug 224659, to name a few.

Maybe the title of this bug should be changed to something more generic and
those bugs should be declared as a duplicates of this one?

Comment 26

[Roland]

It looks like nobody is interesteds in fixing this - so it seems, I should try
and scratch my itch ... while I still have some time for it.

Going to get the tarball (no CVS access) and see what I can do... Any pointers
as to where I should start looking?

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Here's what you have to do. First you have to read this and understand it:
http://ocallahan.org/mozilla/view-talk/

The bug here and in the related bugs is that we do (roughly) the following:
-- a frame F0 has a view V0
-- Create a frame F1 which is a descendant of F0
-- Create a frame F2 and make it a child of F1
-- Create a view V2 for frame F2, nsHTMLContainerFrame::CreateViewForFrame sets
its parent view to V0
-- Create a view V1 for frame F1, nsHTMLContainerFrame::CreateViewForFrame sets
its parent view to V0

The problem is that V2's parent view should be V1, because F2's parent is F1.
The view tree is not in sync with the frame tree. That causes all sorts of badness.

The best solution is to make nsHTMLContainerFrame::CreateViewForFrame search for
descendants of the frame that's getting a view, and reparent those descendants'
views to be children of the new view. This can be done using the view
reparenting function ReparentFrameView.

Comment 28

[Jeremy Bowers]

Attachment: Listbox in popup crashes mozilla

In leiu of filing a new bug, as this seems to be the same one, here's another
test case of a listbox inside of a popup crashing.

Let me motivate this for you. I am attempting to create something similar to
the "autocomplete" fuctionality of the address bar, where the autocompletion
comes from a remote server via RDF. This is working with a collection of
"labels" hacked up with Javascript and CSS to look and act like a listbox, but
I can't use a real listbox. 

Moreover, even using a tree inside the popup seems spotty, though I can't seem
to reduce it to a concise testcase I definately got some crashes. I suspect
that this bug is making the address auto-complete more fragile than it seems on
the surface.

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This works on the trunk now. I fixed this bug a while ago although I don't have
the bug number handy.

Comment 30

[timeless]

*** Bug 268842 has been marked as a duplicate of this bug. ***

Comment 31

[Adam Guthrie]

*** Bug 297574 has been marked as a duplicate of this bug. ***