Thank you for reporting this bug. We will make it our priority to review this report.
  1. #1
    Sencha User
    Join Date
    Sep 2009
    Posts
    34
    Vote Rating
    0
    sacha is on a distinguished road

      0  

    Default [OPEN-980] ToolTip offsets and scrolling

    [OPEN-980] ToolTip offsets and scrolling


    Using ExtJS 3.2.1 and FF 3.6, I had an odd problem with ToolTips on a form. ToolTips are added to each form element as follows:

    Code:
                        new Ext.ToolTip({
                            target: 'caf-panel-div', // div containing form
                            delegate: '#'+fitem.id,  // individual form item
                            html: 'help me',
                            autoHide: true,
                            anchor: 'left'
                        });
    The problem was that for items at the top of the form, the tooltip appeared to the right of the item as expected, but for items lower down the form, the tooltip appeared at the top of the item, as shown in this screenshot:

    tooltip.png

    I traced this to a bug in the ToolTip code; I had to scroll the page down to see the lower form items, but the tooltip positioning code doesn't seem to take account of scrolling in all cases. The following change to getTargetXY fixed it:

    Code:
                    < if(axy[1]+sz.height > dh){
                    ---
                    > if(axy[1]+sz.height > dh+scrollY){
    I expect the same applies to the width check, but I don't have a test case so I haven't checked.
    I had a look in IE8, and my fix works there too.

  2. #2
    Ext User
    Join Date
    Jul 2007
    Posts
    1
    Vote Rating
    0
    netProphET is on a distinguished road

      0  

    Default


    I am experiencing the same symptoms (only in FF), but the fix offered by sacha does not work in my case. My quicktips are on a tree, and the condition at line 30417 is false, so it goes to the code at 30468. If I add the 'scrollY' to the Y portion of the return array, the symptom is fixed in Firefox, but then, not surprisingly, it appears, reversed, in Chrome & IE 8.

Thread Participants: 1

Tags for this Thread