339075 - xul's ephemeral messages are shown in wrong place

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[Allan Beaufour]

If I use hints for f.x. inputs in XUL, funny things happen. Sometimes the window title shows up, and sometimes the control sizes changes?

Comment 1

[Allan Beaufour]

Attachment: Testcase

Try hovering over an input field. First the window title shows up, then the real hint, and sometimes the control itself changes size.

Keeping the mouse hovering makes the control size change constantly

Comment 2

[alexander :surkov (:asurkov)]

(In reply to comment #1)
> 
> Keeping the mouse hovering makes the control size change constantly
> 

Size changing issue was been fixed by bug 345729. Now we get window title tooltip and wrong position of control tooltip. I can't get why window title tooltip is shown and who shows it?

Comment 3

[aaronr]

(In reply to comment #2)
> (In reply to comment #1)
> > 
> > Keeping the mouse hovering makes the control size change constantly
> > 
> 
> Size changing issue was been fixed by bug 345729. Now we get window title
> tooltip and wrong position of control tooltip. I can't get why window title
> tooltip is shown and who shows it?
> 

If I remove the showPopup from xforms-ephemeral-message, the window title still pops up so has nothing to do with our ephemeral message.  I'd suggest simplifying the testcase down by removing xforms from the document.  Instead, put in the xul anonymous content for xforms:input directly into the xul document and see if you still get the title tooltip popping up.  And if it still pops up, you know you need to talk to a XUL guy to see why and how to shut it off.  That is how I'd go about it, at least.

Comment 4

[alexander :surkov (:asurkov)]

(In reply to comment #3)

> If I remove the showPopup from xforms-ephemeral-message, the window title still
> pops up so has nothing to do with our ephemeral message.  I'd suggest
> simplifying the testcase down by removing xforms from the document.  Instead,
> put in the xul anonymous content for xforms:input directly into the xul
> document and see if you still get the title tooltip popping up.  And if it
> still pops up, you know you need to talk to a XUL guy to see why and how to
> shut it off.  That is how I'd go about it, at least.
> 

I posted bug 348467 for additional tooltip issue.

Comment 5

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 6

[alexander :surkov (:asurkov)]

Attachment: patch2

The patch uses xul:tooltip element. It helps us to avoid additional styling.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Does the patch handle the case when xul element is scrolled?

Comment 8

[alexander :surkov (:asurkov)]

(In reply to comment #7)
> Does the patch handle the case when xul element is scrolled?
> 

So, if xtf part of message handles it then my patch it do also :) All I do it's just converting coordinates from message to screen coordinates. Though probably tooltip does some things. What behavior should be?

Comment 9

[alexander :surkov (:asurkov)]

Attachment: testcase2

(In reply to comment #7)
> Does the patch handle the case when xul element is scrolled?
> 

You're right. Sometimes something bougs happens. Though I can't imagine what's wrong and I can't see algoritm. Probably we can save scrolled box issue for bug 348469? At least not scrolled controls works more or less decently.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Do you perhaps have to check whether element is inside a scrollbox or something which has scrollbars and then convert the coordinates...

I think there were some similar problems with select1.
select1.xml#togglePopup does some hackish things to get/set the right coordinates.

Comment 11

[alexander :surkov (:asurkov)]

Attachment: xhtml testcase

(In reply to comment #10)
> Do you perhaps have to check whether element is inside a scrollbox or something
> which has scrollbars and then convert the coordinates...
> 
> I think there were some similar problems with select1.
> select1.xml#togglePopup does some hackish things to get/set the right
> coordinates.
> 

So, that the way how nsIBoxObject::GetHeight() works. You can see the the same behaviour for xhtml too. Probably we should have separate bug for that since these are different issues. So, what do you think?

Comment 12

[alexander :surkov (:asurkov)]

I'd like the next:
1) rename this bug to "xul's empheral messages are shown in wrong place"
2) post new bug "wrong empheral message position for scrolled elements"
3) post new meta bug "empheral messages issues" that will handle two bugs mentioned above and bug 348467.

So we'll get not exactly what Allan talked about but we'll save issues pointed by him in new meta bug. (Note, the meta bug will be wider than this one since some hint problems are represented in xhtml too). I like it too because this patch allows to keep simple uses of hints in xul and I can't guess right now when I'll get a time to fix the rest hint issues. Olli, does it work for you?

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 233436 [details] [diff] [review]
patch2

Sounds ok to me.

Comment 14

[alexander :surkov (:asurkov)]

checked in by smaug for me :)

Comment 15

[aaronr]

checked into 1.8.0 branch on 2006/09/21

Comment 16

[aaronr]

checked into 1.8 branch on 2006/11/21