no titletip displayed for link at bottom of screen and viewport

RESOLVED FIXED

Status

()

Core
XUL
RESOLVED FIXED
13 years ago
9 years ago

People

(Reporter: Felix Miata, Assigned: Peter Weilbacher)

Tracking

Trunk
x86
OS/2
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

13 years ago
To reproduce in OS/2 2005052705 trunk or 20050528 deer park:
1-extend browser window to extreme bottom of screen
2-load some page with a link at the extreme bottom of the viewport
3-mouseover the link

Actual result:
1-nothing

Expected result:
1-tooltip/titletip opens above the mouse pointer
(Reporter)

Comment 1

13 years ago
Created attachment 184776 [details]
screenshot of OS/2 working correctly with link not at screen bottom
(Reporter)

Comment 2

13 years ago
Created attachment 184777 [details]
screenshot of Linux working correctly with link at screen bottom
(Reporter)

Comment 3

13 years ago
Created attachment 184778 [details]
testcase
(Assignee)

Comment 4

13 years ago
That's probably again a problem of the different coordinate system used on OS/2.
I once helped to solve something similar, but I don't find it at the moment. Any
idea what checkin could have triggered this behavior?
(Reporter)

Comment 5

13 years ago
Broken in 1.8a5, OK in 1.8a4, I saved no nightlies in between, and I could find
no OS/2 nightlies on archive.mozilla.org in between.

Comment 6

13 years ago
Peter, this is a side effect of:

https://bugzilla.mozilla.org/show_bug.cgi?id=265841

Note that I'm not going to call it a regression because tooltips didn't work
pretty much at all without your fix for 265841, so this is just probably
something that was missing from your patch.

Updated

13 years ago
Assignee: jag → mozilla
(Assignee)

Comment 7

13 years ago
No, this is not as easy. The coordinates derived in nsWindow::Resize are OK. I
tested this with the tooltip for the Navigator button in the component bar, and
get this debug output:

                    mWnd       size  XP coords   OS/2 coords
nsWindow::Resize 0x80000284, 63 x 22 (668,1000) at 668, 27
nsWindow::Resize 0x80000284, 63 x 22 (668,1018) at 668, 9
nsWindow::Resize 0x80000284, 63 x 22 (668,1023) at 668, 4
nsWindow::Resize 0x80000284, 63 x 22 (668,981)  at 668, 46 (not displayed)

The first three cases are where the tooltip appears, far enough above the lower
end of the screen. In the last case I moved the lower edge of the window a bit
further down, so it does not appear. However, the coordinates seem fine to me so
that it should appear above the mouse pointer. In all the cases !SetWindowPos()
is true and Invalidate is called...

I also found out that in the latter case nsWindow::Show is called very quickly
to "undisplay" it, but it does not help to put a DosSleep in front of the
WinShowWindow( hwnd, FALSE) to actually see the tooltip. Additionally, I tried
to force a differenz z-order, without any change.

At the moment I don't know where to look further...

Comment 8

13 years ago
I noticed that as well. The coordinates definitely seem OK.

So is the problem then that the tooltip appears and then disappears?
(Reporter)

Comment 9

13 years ago
Maybe it's briefly trying to appear. About half the time when I mouseover and
stop sharply I see the hand pointer flinch.
(Assignee)

Comment 10

13 years ago
I thought making a mouse pointer disappear is done by the code in nsWindow::Show
that calls WinShowWindow(hwnd,FALSE), that's why I tried adding a DosSleep
there. That did not cause the tooltip to show up, it just caused a longer delay
before the debug output appeared on the console.

Perhaps I should try again on my slow P166, I just have to get that running,
flickering should be more obvious there. Hmm, and thinking about that, I wanted
to try a debug build with paint flashing as well.
(Assignee)

Comment 11

13 years ago
Created attachment 185822 [details]
debug output

Debug flashing and especially paint dumping helped a little to create this
debug output "diff". The case where the tooltips do appear get an extra
WM_PAINT message. When the tooltip does not appear this message is missing and
the window is undisplayed using nsWindow::Show(PR_FALSE) without getting
painted.

Where and how are these messages created?

Comment 12

13 years ago
Hmm. We don't generate WM_PAINT messages. Not sure where they would come from...
(Reporter)

Comment 13

12 years ago
Problem remains in
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1) Gecko/20060919 SeaMonkey/1.1b
(Assignee)

Comment 14

11 years ago
I just saw bug 306669 and was wondering if it's really an OS/2 widget problem as I had always thought. Perhaps nsMenuPopupFrame, or one of its dependencies (nsXULTooltipListener, nsXULPopupManager), checks the coordinates and gets it wrong on OS/2?
(Assignee)

Comment 15

11 years ago
Another random note to myself:

  379 nsXULPopupManager::ShowPopupAtScreen(nsIContent* aPopup,
  380                                       PRInt32 aXPos, PRInt32 aYPos,
  381                                       PRBool aIsContextMenu)
  382 {
  383   nsMenuPopupFrame* popupFrame = GetPopupFrameForContent(aPopup);
  384   if (!popupFrame || !MayShowPopup(popupFrame))
  385     return;
  386
  387   popupFrame->InitializePopupAtScreen(aXPos, aYPos);

This could be a starting point for debugging...

Comment 16

10 years ago
(In reply to comment #15)
> Another random note to myself:
>   379 nsXULPopupManager::ShowPopupAtScreen(nsIContent* aPopup,
>   ...
> This could be a starting point for debugging...

Yep, think I found there ( nsXULPopupManager ) something interesting ! While nsXULPopupManager::HidePopup( ) is generally called by nsXULTooltipListener::sAutoHideCallback( ) after a delay of a few seconds, it is immediately applied by nsXULTooltipListener::MouseOut( ) if the frame is at the bottom.
So it could be some platform-specific event behaviour making a difference to Windows. Will try to get further ...
(Assignee)

Comment 17

10 years ago
By chance I looked at attachment 318355 [details] [diff] [review] which is the fix for bug 409427. The comments I see in that code reminded me of this problem again. (But again, no time to work on this...)
(Reporter)

Comment 18

9 years ago
I don't use trunk on OS/2 since trunk left 1.8. Has bug 279539 fix changed this behavior?
(Assignee)

Comment 19

9 years ago
No, I'm running SeaMonkey 20081229 and there the problem is still the same.

Comment 20

9 years ago
(In reply to comment #19)
> No, I'm running SeaMonkey 20081229 and there the problem is still the same.
but  SeaMonkey pulls mozilla-1.9.1 (unless you changed that) and the fix of bug 279539 was yet applied only to mozilla-central. My mozilla-central minefield 3.2a1pre of 20081217 does not show tooltips at the bottom while all builds after 20081220 (when the fix was checked in) do, e.g. "Authenticated by Equifax" when I hover over the lock symbol after bugzilla.mozilla.org in the status bar.
(Assignee)

Comment 21

9 years ago
Right. I thought that branching was after that checkin but that was clearly wrong (GECKO_1_9_1_BASE was tagged on Nov 29th).

   Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1b3pre)
   Gecko/20090109 Shiretoko/3.1b3pre
still shows the problem but with
   Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.2a1pre)
   Gecko/20090110 Minefield/3.2a1pre
it's fixed. (I'll upload that nightly in a second.)

If one only waits long enough to resolve a problem it gets fixed by someone else, great. :-)
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Depends on: 279539
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.