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)
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
Reporter | ||
Comment 1•19 years ago
|
||
Reporter | ||
Comment 2•19 years ago
|
||
Reporter | ||
Comment 3•19 years ago
|
||
Assignee | ||
Comment 4•19 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•19 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•19 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•19 years ago
|
Assignee: jag → mozilla
Assignee | ||
Comment 7•19 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•19 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•19 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•19 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•19 years ago
|
||
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•19 years ago
|
||
Hmm. We don't generate WM_PAINT messages. Not sure where they would come from...
Reporter | ||
Comment 13•18 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•17 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•17 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•16 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•16 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•16 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•16 years ago
|
||
No, I'm running SeaMonkey 20081229 and there the problem is still the same.
Comment 20•15 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•15 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. :-)
You need to log in
before you can comment on or make changes to this bug.
Description
•