Closed Bug 295833 Opened 19 years ago Closed 15 years ago

no titletip displayed for link at bottom of screen and viewport

Categories

(Core :: XUL, defect)

x86
OS/2
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mrmazda, Assigned: mozilla)

References

Details

Attachments

(4 files)

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
Attached file testcase
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?
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.
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.
Assignee: jag → mozilla
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...
I noticed that as well. The coordinates definitely seem OK.

So is the problem then that the tooltip appears and then disappears?
Maybe it's briefly trying to appear. About half the time when I mouseover and
stop sharply I see the hand pointer flinch.
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.
Attached file 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?
Hmm. We don't generate WM_PAINT messages. Not sure where they would come from...
Problem remains in
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1) Gecko/20060919 SeaMonkey/1.1b
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?
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...
(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 ...
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...)
I don't use trunk on OS/2 since trunk left 1.8. Has bug 279539 fix changed this behavior?
No, I'm running SeaMonkey 20081229 and there the problem is still the same.
(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.
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
Closed: 15 years ago
Depends on: 279539
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: