Closed Bug 517930 Opened 15 years ago Closed 3 years ago

Inconsistent explicitOriginalTarget from identical action

Categories

(Core :: DOM: Events, defect, P5)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 662335

People

(Reporter: dragoncloak, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GIS IE 6.0 Build 20080321; .NET CLR 2.0.50727; .NET CLR 1.1.4322; InfoPath.2; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; MS-RTC LM 8)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

The value of the explicitOriginalTarget property of the onbeforeunload's event object is inconsistent when the user takes conceptually identical actions (specifically, a browser level close using the "X" with two tabs open) that should result in an indentical source for the raised event.

The additional information field holds two html pages that demonstrate the problem.

Reproducible: Always

Steps to Reproduce:
Save the additional information data as two files with the given names.  

1. Open page.main.htm.
2. Click the "Open" link.  This will open and give focus to a new page in a new tab.
3. Click the "X" of the browser to close it.
4. Note the reported name (e.g. "It thinks it name A.")
5. Click Cancel.
6. Select the newer tab (may not be necessary, but this leaves the UI in the same [at least visual] state as previous).
7. Click the "X" of the browser to close it.
4. Note that the reported name is different (e.g. "It thinks it name #document.")

Actual Results:  
The explicitOriginalTarget is different.

Expected Results:  
The explicitOriginalTarget is consistently the same object (and probably that it is further some element that indicates that the event occurred because of a closure request that originated outside of the page, even if anonymously reporting the source as "the browser", like window).

page.main.htm:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
    <title>Untitled Page</title>
    <script language="javascript" type="text/javascript">
    function report(oEvent) {
        var alertStr = "Me thinks it the ";
        if(oEvent.explicitOriginalTarget == window ) {
            alertStr += "window.";
        }
        else if(oEvent.explicitOriginalTarget == document) {
            alertStr += "document.";
        }
        else if(oEvent.explicitOriginalTarget == document.documentElement) {
            alertStr += "documentElement.";
        }
        else {
            alertStr += "other.";
        }
        alertStr += "\nIt thinks it name "+oEvent.explicitOriginalTarget.nodeName+".\n";
        return alertStr;
    }
    </script>
    <script language="javascript" type="text/javascript">
        var isChild = (window.opener != null);
        window.onbeforeunload = report;
        function openLinkClick() {
            var w = window.open("page.main.htm");
            w.focus();
        }
        function closeLinkClick() {
            alert("Closed (Link)");
            if(isChild) { window.close(); }
            else { window.location.replace("page.main.htm"); }
        }
    </script>
</head>
<body>
    <table>
    <tr><td><script>
    if(isChild) { document.write("Child"); }
    else { document.write("Parent"); }
    </script></td></tr>
    <tr><td><br /><br /></td></tr>
    <tr><td><br /><br /></td></tr>
    <tr>
    <td><a name="openLink" href="javascript:openLinkClick();">Open</a></td>
    <td>&nbsp;&nbsp;&nbsp;</td>
    <td><a name="closeLink" href="javascript:closeLinkClick();">Close</a></td>
    </tr>
    </table>
</body>
</html>

page.edit.htm:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head><title>exit</title></head>
<body onload="close();">
If you end up seeing this, then you are in the parent window.
</body>
</html>
C.f. bug 517007 where smaug says it should just be removed.

FWIW, I didn't understand how the second page is used to reproduce.
Component: Tabbed Browser → DOM: Events
Depends on: 517007
Product: Firefox → Core
QA Contact: tabbed.browser → events
Apologies, the pages given were distilled down from a larger prototype of the concept I was building.  You are correct that the second page is not relevant.

If the explicitOriginalTarget is removed, this bug is certainly irrelevant and should be marked resolved.  (Is that my responsiblity?  I'm not familiar with the dev community and the roles played and thereby the amount of authority behind smaug's proclamation...)

The reason that explicitOriginalTarget was useful in my case was that I was implementing onbeforeunload handling in a web application that has existed for some time and thereby has a large amount of legacy.  This coupled with further factors meant that without determining whether the event occurred upon the page or whether it originated from the browser (or tab) I could implement the feature generally without introducing bugs into the system.  

In the end, because of the challenges of accomplishing this, as weighted against the value of the feature, we have proceeded, accepting that bugs will be introduced, and will fix the bugs as they are found.  As such, this is no longer relevant to the system.  

However, one of the greater challenges of good system development in the web sphere is hidden factors which make the context indeterminate or untrustworthy without extensive testing and intricate evaluations of the context (though even this is insufficient at times).  The reason I submitted the bug, in the large, is that looking at the issue underlying this inconsistency could be a step towards addressing such issues.
I still don't understand why you use explicitOriginalTarget with beforeunload event. Why not just .target?
I used explicitOriginalTarget because, as I recall, it was much more accurate with regards to exactly how the user action, which resulted in the unload through a chain of javascript calls, was initiated.  Target, as I recall (though explicitOriginalTarget was not entirely outside of this), was further removed from the user action and much more tightly related to the manner in which that action interacted with and was processed by the DOM model and its implementation.  The more specific and to-the-task relevant question I was asking was "did this unload come from something we placed on the web page or from a general browser means?".  The marquee means of closure we were interested in warning against was the browser window's "X".

To explain with context: given the legacy of the system and time constraints I was working within, I could not alter the entire system but I could also not guarantee that system's state hadn't been changed (in a way that would need to be reversed) prior to initiation of the unload.  Effectively, the web app hadn't been implemented keeping in mind the possibility that the user could cancel that action they had taken.  Because of this, I couldn't guarantee that the page would not be left in a bad state if the user was allowed to cancel the closure that our html/code/etc. had caused; this (of course) made it safe to cancel any unload "we" had not originated and unsafe to cancel unloads we caused ourselves.  The complete implementation would have been implemented in a further iteration of the project by thoroughly reviewing and correcting the system to account for user cancellation.

Thank you for taking the time to review this.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
No longer depends on: 517007
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.