Open Bug 669511 Opened 15 years ago Updated 2 years ago

Tooltip (title attribute) is drawn on top left after reload/refresh

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
All
Other
Type:
defect

Tracking

()

People

(Reporter: guijoselito, Unassigned)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

testcase html
1.13 KB, text/html
Details
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110704 Firefox/7.0a1 Build ID: 20110704030740 Steps to reproduce: Go to http://ts3.travian.com.br/login.php Move the mouse to the text "Home", but don't click on it. A black tooltip box with some text will appear. Hit F5, don't move the mouse. Actual results: The tooltip is drawn on top left of the page. Expected results: The tooltip should be drawn where the mouse is. The problem happens on Firefox 5 and on Nightly. It works correctly on Google Chrome 12.
Able to confirm on Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110905 Firefox/9.0a1 ID:20110905030839 This does not occur in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.21) Gecko/20110830 Firefox/3.6.21 ID:20110830092825 Guilherme -> Would you be interested in tracking down a regression window? http://harthur.github.com/mozregression/ Quick search for dupes didn't find any...
URL: http://ts3.travian.com.br/login.php
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
Summary: Tooltip is drawn on top left after reload → Tooltip (title attribute) is drawn on top left after reload/refresh
Version: unspecified → Trunk
pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=01fa971e62ee&tochange=0886ad6e6aaa Triggered by Bug 130078 - integrate iframe into chrome view hierarchy (link view managers / trees between chrome and content)
Blocks: 130078
Keywords: regressionwindow-wanted
A standalone testcase would be wonderful here (something I can edit), even if it isn't reduced or even small at all.
Attached file testcase html (obsolete) —
I think that the similar behavior can reproduce in this testcase.
Attached file testcase html —
Attachment #592618 - Attachment is obsolete: true
Thank you, that is wonderful.
20160502172042 Mozilla/5.0 (Windows NT 5.1; rv:46.0) Gecko/20100101 Firefox/46.0 20160519030232 Mozilla/5.0 (Windows NT 5.1; rv:49.0) Gecko/20100101 Firefox/49.0 I have tested your issue on latest FF release 46.0.1, latest Nightly build 20160519030232 and managed to reproduce it. The page from STR is not available anymore. I tested with testcase attached in comment5(https://bugzilla.mozilla.org/attachment.cgi?id=592621) and the issue is reproducible.
Severity: normal → S3

To me it seems to work with the attached testcase these days, maybe someone else wants to take a look before closing.

Severity: S3 → --
Component: General → DOM: Events

I can repro with the given attached test case on Nightly/MacOS.

Severity: -- → S3

(In reply to Jan Jaeschke [:jjaschke] from comment #9)

I can repro with the given attached test case on Nightly/MacOS.

Interesting, I was testing on Windows.

Repros on Ubuntu as well.

For me this still reproduces on Windows 10

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: