Open Bug 65625 Opened 25 years ago Updated 14 years ago

javascript: urls in sidebar can't access window properties that onclick handlers can access

Categories

(SeaMonkey :: Sidebar, defect, P3)

Product:
SeaMonkey
Component:
Sidebar
Type:
defect

Tracking

(Not tracked)

People

(Reporter: shrir, Unassigned)

References

Details

Attachments

(1 file)

testcase from comment #9
898 bytes, text/html
Details
Build used: 2001011604 Steps: 1. Open Sidebar Stoks tab 2. Click on the 'Edit' button at the bottom of the panel 3. Observe that nothing happens and the following is seen in the console : " Javascript Error : line 0 :open_window is not defined " Expected : A customize tab window should open up.
This is scary. open_window isn't defined when the page is a sidebar panel, but works if I open it as a local file. Ideas, anyone?
Blake? I see it defined right below the <style> block in the <head> of the page.
Yes, it's defined in the JS, but it's throwing an error that it isn't when it's a sidebar panel.
Sorry, misread your comment.
spam : changing qa to sujay (New Sidebar QA)
QA Contact: shrir → sujay
Marking nsbeta1+, p2, mozilla0.9.1
Keywords: nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.1
Hyatt, This seems like a _content bug. The proper behavior is that a new window should open with the edit contents. Instead what is happening is we are getting that error and nothing is happening. If i load the tab into my content window: url below http://my.netscape.com/sidebar/wrapper.tmpl?mn_yes=1&service=stocks&sbar=YES then i click on edit the a new window opens. Then if i close that new window. click on my sidebar tab edit button the window now opens and works as expected. Handing off to hyatt for more investigation.
Assignee: matt → hyatt
Reassigning to danm.
Assignee: hyatt → danm
Target Milestone: mozilla0.9.1 → ---
Maybe danm already knows what this is about but anyways ... If I use the following as my sidebar panel, if the <base href> refers to target='_content', then the <a href='javascript:...'> will throw this error: JavaScript error: line 0: uncaught exception: [Exception... "Access to property denied" code: "1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)" location: "<unknown>"] However, a reference to the same property (window.open_window) will succeed if it is done in an onclick handler. ------------------------------------------------------------ <html> <head> <base href="http://my.netscape.com/" target="_content"> <script> function open_window() { window.open('http://my.netscape.com/', 'openwindow', 'toolbar=no,location=no,directories=no,status=no,scrollbars=yes,' + 'resizable=yes,copyhistory=no,width=670,height=620'); } </script> </head> <body> As a 'javascript:' URL in an &lt;A HREF&gt;, throws DOM PROP exception<br> <a href='javascript: if (window.dump) dump("have " + window.open_window + "\n"); open_window(); '><img src='http://my.netscape.com/mys/images/edit.gif' border=0></a> <br> As an onclick handler in an &lt;INPUT TYPE=IMAGE&gt;, no problemo<br> <input type='image' src='http://my.netscape.com/mys/images/edit.gif' onclick='if (window.dump) dump("have " + window.open_window + "\n"); open_window();' > <body> </html> ------------------------------------------------------------------
Does removing the <base href> and moving the target=_content onto individual non-JS links fix the problem for this tab? Btw, it seems like this bug was indirectly caused by bug 27162, "Default link target should be most recently used browser".
This might be related to bug 73203, which seems like a similar javascript vs. html window targeting bug...
I don't see the Edit button anymore, just a View Portfolio Manager link that works as expected.
Um, yeah. The panel pushed out by netscape has changed. The test case above (and at http://jrgm.mcom.com/bugs/65625/panel.html) can be used as the panel (edit panels.rdf in a profile to point to the http url). The error is now: JavaScript error: line 0: uncaught exception: Permission denied to access property instead of the previous NS_ERROR_DOM_PROP_ACCESS_DENIED error, but the meaning is the same. (I assume it changed with the xpcdom and caps changes from yesterday).
Using US Windows, Netscape 6.1b US build: * Stocks tab loads properly, but.... * The arrow in the upper right corner is dead * The View Portfolio Manager link is dead Cindy Roberts sees slightly different behavior. When she clicks View Portfolio Manager, she sees a js call in the bottom of chrome in the browser windowm but nothing else happens. Cindy, please note your environment--is it Mac? 6.1b? Adding Cindy Roberts to cc-list
Please do NOT add comments that have nothing to do with the specific bug described here.
Er, to be a bit less grouchy ... the problem in the current 'Stocks' sidebar is a problem with the content served from my.netscape.com. There is a syntax error in a JS file. That means that some functions and properties do not get defined, and when you click on the links, you will get JS errors in the JS console. So, that is not a bug in mozilla, but you might want to report this to the relevant folks at netscape.com.
What "Edit" button are all of you talking about? I see a "View Portfolio Manager" button which did not work for sometime, but not it magically works. Someone from netscape.com fixed something on server side... If you're all referring to the "View Portfolio Manager" button this is now functioning....
I was able to add a stock symbol to the Stocks Sidebar today. Clicked on "View Portfolio Manager" to do this. I believe the bug can be closed.
See my comments 2001-05-09 21:43. This bug is about the testcase panel http://jrgm.mcom.com/bugs/65625/panel.html, and it is a security issue based on the original former stocks tab.
QA Contact: sujay → jrgm
smells like a security issue.
Assignee: danm → mstoltz
Since this bug was based on the old stocks tab (which is no longer accessible), can it be closed? Or is there some takeaway from this that affects the current tab?
Once again ... > See my comments 2001-05-09 21:43. This bug is about the testcase panel > http://jrgm.mcom.com/bugs/65625/panel.html, and it is a security issue > based on the original former stocks tab. In the sidebar, a 'javascript:' URL does not have the same access to the properties of the window that an onclick handler does.
Summary: Edit button in Sidebar 'Stocks' tab does not work → javascript: urls in sidebar can't access window properties that onclick handlers can access
Yes, this still an issue. It now has nothing to do with the Stocks tab, but it's still a bug.
Status: NEW → ASSIGNED
Priority: P2 → P3
Target Milestone: --- → mozilla0.9.3
milestone 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Moving to 0.9.5.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
time marches on. Retargeting to 0.9.6.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
performance, footprint, feature work, and re-architecture bugs will be addressed in 0.9.8
Target Milestone: mozilla0.9.6 → mozilla0.9.8
Mozilla1.0
Target Milestone: mozilla0.9.8 → mozilla1.0
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Target Milestone: mozilla1.2alpha → Future
Product: Browser → Seamonkey
Assignee: security-bugs → sidebar
Status: ASSIGNED → NEW
QA Contact: jrgmorrison
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → EXPIRED
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
Problem still there, error is currently: JavaScript error: , line 0: uncaught exception: ReferenceError: window is not defined
Assignee: sidebar → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: sidebar
Hardware: x86 → All
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: