Closed Bug 59430 Opened 24 years ago Closed 24 years ago

BASE HREF not affecting applets

Categories

(Core Graveyard :: Java: OJI, defect, P3)

Product:
Core Graveyard
Component:
Java: OJI
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: nasiruddin.shaikh, Assigned: alexsavulov)

References

(
URL
)

Details

(Whiteboard: suntrak-n6 fix-in-hand [oji_working])

Attachments

(5 files)

propsed patch
(deleted), patch
Details | Diff | Splinter Review
testcase in attachment form
(deleted), text/html
Details
update patch to use nsCOMPtr<what ws I thinking before!> got the verbal sr= from Marc
(deleted), patch
Details | Diff | Splinter Review
modified peterl's patch nr.1, added NS_RELEASE calls, tested with <base href=...> and it works
(deleted), patch
Details | Diff | Splinter Review
much more simple patch that works
(deleted), patch
Details | Diff | Splinter Review
Netscape build id : 10/31 Platform : Solaris2.8(sparc) Please see the Bug-id 40275. I tested this on SOLARIS and it gives the following security exception. java.security.PrivilegedActionException: java.lang.reflect.InvocationTargetException: java.lang.NullPointerException at JavaToJS.doCallTest(JavaToJS.java:146) at JavaToJS.callTest(JavaToJS.java:113) at java.lang.reflect.Method.invoke(Native Method)
Whiteboard: suntrak-n6
Hi Joe, Can you please test this? Thanks, Ed
Assignee: edburns → joe.chou
The problem is that when Java plugin calls nsPluginInstanceOwner::GetDocumentBase (in .../layout/html/base/src/nsObjectFrame.cpp) for the document base URL, GetDocumentBase always returns the document URL regardless if base URL defined or not. That causes the browser failed to find the applet code if a page has base URL defined. GetDocumentBase should return base URL if exists, otherwise return document URL. Therefore, I am re-assigning this bug to layout component. NS_IMETHODIMP nsPluginInstanceOwner::GetDocumentBase(const char* *result) { nsresult rv = NS_OK; if (nsnull == mDocumentBase) { if (nsnull == mContext) { *result = nsnull; return NS_ERROR_FAILURE; } nsCOMPtr<nsIPresShell> shell; mContext->GetShell(getter_AddRefs(shell)); nsCOMPtr<nsIDocument> doc; shell->GetDocument(getter_AddRefs(doc)); nsCOMPtr<nsIURI> docURL( dont_AddRef(doc->GetDocumentURL()) ); rv = docURL->GetSpec(&mDocumentBase); } if (rv == NS_OK) *result = mDocumentBase; return rv; }
Assignee: joe.chou → karnaze
Component: OJI → Layout
*** Bug 40275 has been marked as a duplicate of this bug. ***
*** Bug 39609 has been marked as a duplicate of this bug. ***
cc-ing some folks who know about plugins, and might know what to do here, or have suggestions on how to properly regression test it once it's fixed.
Joe, I just un-duped bug 39609 since I don't think it's a dup. Please have one more look and explain why it's a dupe if it really is...
Assignee: karnaze → av
Reassigning to av.
George, would you please get one of your folks to look at it?
Assignee: av → drapeau
Component: Layout → Java-Implemented Plugins
moving to oji
Component: Java-Implemented Plugins → OJI
Av, I don't understand why you re-assign this problem back to George's group, without leaving any reasons. Did you take a look at the previously attached comments about why this problem was re-assigned to layout component? The problem here is that when Java plugin calls GetDocumentBase() (in layout) for the base URL of the document, GetDocumentBase() ignores if a base URL is defined in the document, and always returns the document's URL (current URL), which causes the browser fail to find the applet's class. NS_IMETHODIMP nsPluginInstanceOwner::GetDocumentBase(const char* *result) (underlayout/html/base/src) needs to be modified, so that it returns the document's base URL if it is defined; otherwise return the document URL.
By the way, let me introduce myself. I am one of the folks in George's group, providing support of OJI on Solaris and Linux.
Re-assign to layout owner.
Assignee: drapeau → karnaze
Component: OJI → Layout
OK, I guess it is my again.
Assignee: karnaze → av
Attached patch propsed patch (deleted) — — Splinter Review
Can someone try out the patch and let me know if it works? I don't have a Sun nor am setup to test this.
I wonder why it is Solaris specific...
Me too..... Adding qawanted
Assignee: av → peterlubczynski
Keywords: qawanted
I tried the patch on my Solaris machine, and the patch seemed working. I only tried a simple test case (see attachment below), so the test may not be conclusive. Please review for preventing from any possible side-effects. The test case's html (with a simple "hello world" applet): <html> <head> <title>Applet Test</title> <base href="http://javaweb.eng/~joechou/testbase/"> </head> <body> <center> <h1>Applet Test 1 j</h1> <applet CODE = "FirstApplet_base.class" WIDTH= 100 HEIGHT = 100 border=10> </applet> </center> </body> </html>
Attached file testcase in attachment form (deleted) —
Ok, I think this patch works on Windows too, but I'm not sure because I couldn't get the applet to work in any browser without getting exceptions about javaweb.eng. And that's why I think it works. In IE fails and says it can't resolve javaweb.eng even the though the page is being served from bugzilla and locally. After applying the patch, in Windows, we fail with the same execption. Different exception before the patch. I think this did the trick, but I'd like to be a little more sure with a testcase that actually works unless we are in agreement that it works. BTW, I thought security could be involved, but I did check the W3C spec and it says that applets are effected by the BASE tag: http://www.w3.org/TR/html4/struct/links.html#edef-BASE Accepting and changing spects
Status: NEW → ASSIGNED
Keywords: qawanted
OS: Solaris → All
Hardware: Sun → All
Target Milestone: --- → mozilla0.9
Peter, can you please try your patch with bug 69466?
Keywords: patch
Whiteboard: suntrak-n6 → suntrak-n6 fix-in-hand
Tried it, didn't do anything different. I think that bug is a WFM anyway. I'll see if I can whip up a testcase in Java. I'm a little rusty with the Applet classes but I think JBuilder may help. :)
Moving to mozilla0.8.1
Target Milestone: mozilla0.9 → mozilla0.8.1
Target Milestone: mozilla0.8.1 → mozilla0.9
If someone could create a Java testcase that calls GetDocumentBase() that would be really helpfull for fixing this bug. Thanks. bug 69466 is another issue I think.
-->0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Reassigning to OJI group as I won't have cycles to fix this for 0.9.1 but there is already an untest patch attached.
Assignee: peterlubczynski → edburns
Status: ASSIGNED → NEW
Component: Layout → OJI
a
Status: NEW → ASSIGNED
Whiteboard: suntrak-n6 fix-in-hand → suntrak-n6 fix-in-hand [oji_working]
Works with today's trunk on win32.
Doesn't work on linux.
I was wrong, this does work on linux.
Ed, does this work with my patch?
Yes, it works on win32 and linux.
Ed, can I get an r= from you for check-in?
Assignee: edburns → peterlubczynski
Status: ASSIGNED → NEW
Looks like there is a leak in the patch - GetBaseURL does an addref...
This appears to be on the verge of getting fixed. peterl, do you think this will fix the security exceptions we get when opening socket connections to the document base? I'm just doing read(byte[]) type operations from InputStream .
Moving to m0.9.2.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
-->Alex
Assignee: peterlubczynski → alexsavulov
OOPS!... forget attachment (id=37083)...
peterl verbal r= on patch id=37088
sr=attinasi
Blocks: 83989
a=blizzard on behalf of drivers for the trunk
Patch checked in, marking FIXED. /cvsroot/mozilla/layout/html/base/src/nsObjectFrame.cpp,v <-- nsObjectFrame.cpp new revision: 1.219; previous revision: 1.218
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 84662 has been marked as a duplicate of this bug. ***
Verify bug 40275 fixed in build 2001061304.
v
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: