Closed Bug 288717 Opened 20 years ago Closed 19 years ago

image.x and image.y properties are incompatible with both netscape or IE

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED EXPIRED

People

(Reporter: spagmoid, Unassigned)

Details

(Keywords: qawanted) 

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Alexa Toolbar; .NET CLR 1.1.4322)
Build Identifier: 1.0

For nested controls, object.x property is incorrect, making it incompatible 
with other browsers for determining mouse position (such as over an image).  
$Obj refers to the "this" object passed from <IMG onMouseDown="funcname(this)">

In IE, the following works:
		$MouseOffsetX = $Event.offsetX;
In Netscape, the following works:
		$MouseOffsetX = $Event.pageX-$Obj.x;
In FireFox, the value of $Obj.x is not compatible with Netscape.

Reproducible: Always

Steps to Reproduce:
see details
Actual Results:  
see details

Expected Results:  
see details

see details

*** This bug has been marked as a duplicate of 271129 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Why was the other bug marked as invalid?  This is not invalid.  If so, there 
should be a comment as to why.  This one should remain open since the other 
has less specific details.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Because that bug is only about IE.  Obviously FireFox isn't going to want to 
follow IE (even though it would make things easier for millions of 
developers), but my report clearly states that FireFox is ALSO not compatible 
with Netscape.  "Obj.x" is a wrong value in FireFox.  Being incompatible with 
IE is one thing, but being incompatible with BOTH ie and netscape?  You tell 
me how a developer is supposed to determine mouse position then...
(In reply to comment #4)
> Being incompatible with 
> IE is one thing, but being incompatible with BOTH ie and netscape?  You tell 
> me how a developer is supposed to determine mouse position then...

Which version of Netscape? All recent Netscape releases have used the same core
rendering code as Mozilla Suite and Firefox. And if you read bug 271129 comment
1, you'd see that the Netscape 4.x behavior is not going to be supported, since
it was wrong.

Firefox uses the standard DOM mouse events, as defined at
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-MouseEvent .
Several versions, possibly all of them, between 6 - 7.  I don't know about the 
latest.  Being compatible with Netscape 4 isn't important.

However, the problem is not in the event model, if you read the report.. it is 
with a nested object's X & Y.
The report isn't clear on what the problem actually is. Can you attach a clear,
simple testcase that uses actual working code? Clear and concise expected and
actual results would be useful too.
Assignee: bugs → events
Component: JavaScript Console → DOM: Events
Product: Firefox → Core
QA Contact: js-console → ian
Version: unspecified → 1.0 Branch
It can't get much simpler.
"For nested controls, object.x property is incorrect"
make a nested object, such as an image in a table.  examine the x property in 
netscape and firefox.  In one the property is an offset, in the other it's 
absolute.
The .x and .y properties are mapped to .offsetX and .offsetY, to be compatible
with Netscape 4.x. This behavior has never been defined by the W3C, so
compatibility with 4.x was chosen.

Reference:
bug 98292
bug 116843
Assignee: events → general
Component: DOM: Events → DOM: Level 0
OS: Windows XP → All
Hardware: PC → All
Summary: javascript incompatibility with either netscape or ie → image.x and image.y properties are incompatible with both netscape or IE
Version: 1.0 Branch → Trunk
Ahh I see, well I vote for compatibility with a product people still develop 
for, like NS6! :)
Spagmoid, if Firefox and Mozilla are ever going to support the x and y event
properties, it will have to be compliant with MSIE's implementation of these
event properties. This is what Opera has been trying to do too (b 123298 at
Opera's bug tracking system) and they still have not so far. event.x, event.y
should return the x, y coordinate values within a relatively positioned element.

Also note bug 16475 comment 3: event.x and event.y were duplicating layerX and
layerY. And still readable here:

http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/event.html#1197547

Resolving as DUPLICATE of bug 271129

*** This bug has been marked as a duplicate of 271129 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → DUPLICATE
Well if you are closing the bug at least do it for the right reason.  As I 
have said before, this has NOTHING to do with the event.x
It is any NESTED OBJECT's .x

The Event.x is fine.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
> Well if you are closing the bug at least do it for the right reason.  As I 
> have said before, this has NOTHING to do with the event.x
> It is any NESTED OBJECT's .x
> 
> The Event.x is fine.

If you are going to open a bug, then try to always provide the necessary and
required info as described in the guidelines for writing useful bugfiles
http://www.mozilla.org/quality/bug-writing-guidelines.html
like 
- an url where we all can examine how/where the problem you see is happening:
e.g.: what does funcname do? I have no idea. But going to a provided url might
answer that.
- clear and explicit steps to reproduce what you believe is a bug
- clear and explicit "Actual results" and "Expected results"; in that way, we
should, must and will close the bug when the expected results are achieved
- a reduced testcase where we all can see in the code where image.x property,
image.y property come from, refer to and mean in terms of DHTML: if these come
from custom functions or custom js objects, then it is your responsibility to
provide such specifics to the bugfile. 
Same thing with custom variables like $Event.pageX, $Obj.x and others: in the
absolute, these mean nothing, these refer to nothing since no one can see with
regard to which coordinates references system these variable refer to. The
coordinates references system could be the document, it could be the
offsetParent node, it could be the immediate parent element, it could be the
body node, it could be the available screen area, it could be the work area for
applications, it could be the target node in case of an event, etc...

It is your responsibility to provide all necessary details in the bugreport so
that the bug you see can be examined, investigated, addressed and fixed. No one
can see what does "funcname" function do. No one can see where $Event.pageX and
$Obj.x come from, how they are calculated, etc.. Reminder: we are all volunteers
spending time trying to improve the product you are using.

------------

I had a talk with Gavin at irc://moznet/bugs

You said:

"In Netscape, the following works:
		$MouseOffsetX = $Event.pageX-$Obj.x;
In FireFox, the value of $Obj.x is not compatible with Netscape."

Then please elaborate on this. The cross-browser code I use for determining the
x,y coordinates inside a target element on a mouseclick event for Netscape 6
also works accordingly for NS 7.x, Firefox 1.x and Mozilla 1.x:

At this page:

http://www.gtalbot.org/HTMLJavascriptCSS/DUWindowsNS6.html

you can read

[
Here's a way to get the equivalent of MSIE 5+ event.offsetX/Y properties:

var Element = evt.target ; 
var CalculatedTotalOffsetLeft = CalculatedTotalOffsetTop = 0 ; 
while (Element.offsetParent) 
{ 
CalculatedTotalOffsetLeft += Element.offsetLeft ; 
CalculatedTotalOffsetTop += Element.offsetTop ; 
Element = Element.offsetParent ; 
} ; 
OffsetXForNS6 = evt.pageX - CalculatedTotalOffsetLeft ; 
OffsetYForNS6 = evt.pageY - CalculatedTotalOffsetTop ;
]
Keywords: qawanted
I think I gave enough info, I simply don't have the time to spend on this any 
more.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.