Closed
Bug 129250
Opened 23 years ago
Closed 22 years ago
MRJ plugin can't use XPCOM interfaces using AUTF8String and ACString parameters
Categories
(Core Graveyard :: Java: OJI, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.0
People
(Reporter: darin.moz, Assigned: bnesse)
Details
Attachments
(3 files)
5.30 KB,
patch
|
Details | Diff | Splinter Review | |
7.34 KB,
patch
|
beard
:
review+
darin.moz
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
7.34 KB,
patch
|
beard
:
review+
darin.moz
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
i ran into some trouble while trying to land my patch for bug 124042. the changes make some of the necko interfaces use the new AUTF8String XPIDL string type. this causes problems for the MRJ plugin since it doesn't link to anything mozilla. i guess we either need a separate API for MRJ or MRJ needs to know about our string interfaces. added #ifdef NOT_BROKEN_BY_DARIN around string-fu that wouldn't link in LiveConnectNativeMethods.cpp. this most likely breaks the MRJ plugin.
And because string depends on intl, it can't just link against string, right? What a tangled web we weave... Glue library to the rescue?
Comment 2•23 years ago
|
||
Even worse, this means we have a binary incompatibility with the plugin and existing browsers. Luckily the MRJ plugin for Mac OS 9 is built with the browser, but the MRJ plugin for Mac OS X isn't and this is a bug that's going to bite us soon. I need to be able to build a plugin that works with both NS 6.2.1 and later browsers on Mac OS X. This looks to be impossible now. My fault for using a non-frozen interface.
Reporter | ||
Comment 3•23 years ago
|
||
we have a couple of options: 1) add more dependencies (statically linked into) the MRJ plugin. 2) eliminate necko, do the URL parsing ourselves. 3) use nsIURLParser that still works w/ |string|. i'd like to avoid bloating the MRJ plugin, so (1) seems bad. if we go w/ (3) then we're in the same boat... depending on a non-frozen interface. so, moving forward option (2) might be best... especially considering that the MRJ plugin only wants to parse out the prePath from an URL. but all of these options seem to require some sort of runtime version/interface checking that i simply don't know how to satisfy :(
Comment 4•23 years ago
|
||
I'd lean towards (3) and freeze nsIURLParser, personally.. we'd bloat the mrj plugin slightly, but not as bad as (2) (1) seems bad all together. we COULD have people link against libstring_s.lib or whatever it's called, but again, it would add bloat.
Reporter | ||
Comment 5•23 years ago
|
||
i really don't want to freeze nsIURLParser :( also, in order to use nsIURLParser we have to make it non-scriptable... since making it scriptable would require using AUTF8String parameters, which wouldn't help the MRJ plugin any. i suppose this isn't much of an issue since there isn't any JS code calling into nsIURLParser (or else it would be broken on i18n sites). hmm... it wouldn't be that much code to parse out the prepath.
Comment 6•23 years ago
|
||
Most embedders and component developers may already need to link with both xpcom/glue and strings. Sure this is bloat, but that is the price ya gotta pay until both things are frozen. exactly how much crap will be pulled in if we wanted to support AUTF8String and ACString parameters?
Reporter | ||
Comment 7•23 years ago
|
||
well.. the MRJ plugin only needs: nsDependentCString - for setting AUTF8String attribute values nsCAutoString - for getting AUTF8String attribute values IOW if the code factors nicely, we might be able to get away with few additional dependencies.
Reporter | ||
Comment 8•23 years ago
|
||
patrick: where does the url string come from that we're wanting to parse? if it comes via the plugin API, then chances are that it has already been canonicalized. in which case, it should be fairly trivial to parse the prePath manually. just search for the third '/' or if no '/' after the first ':' then use the entire url string as the security context origin. sound good?
Comment 10•22 years ago
|
||
This patch fixes the bustage in the Mac OS X Java plugin, and stops using the unfrozen nsIIOService & nsIURI interfaces. Instead, it assumes the URL it stores in its mLocation field is in canonical form, and NULL terminates the string at the 3rd slash. The patch also fixes the plugin so that it uses nsIComponentManagerObsolete instead of nsIComponentManager, so that will be binary compatible with Mozilla 0.9.4 and later.
Comment 11•22 years ago
|
||
Brian, please migrate this patch to the classic MRJ plugin.
Comment 12•22 years ago
|
||
Nominating for nsbeta1.
Keywords: nsbeta1
Target Milestone: --- → mozilla1.0
Reporter | ||
Comment 13•22 years ago
|
||
patrick: noticed one thing... allocating mLocation w/ ::strdup and deallocating with delete[]. might this be a problem?
Updated•22 years ago
|
Comment 14•22 years ago
|
||
No, this strdup is part of the plugin source code in mozilla/plugin/oji/MRJCarbon/plugin/Source/StringUtils.cpp which uses |operator new()| to allocate the string.
Reporter | ||
Comment 15•22 years ago
|
||
fair enough :)
Comment 16•22 years ago
|
||
I checked in the MRJPluginCarbon patch, since it is needed to fix bustage.
Reporter | ||
Comment 17•22 years ago
|
||
you might want to check this in on the 0.9.9 branch as well since my changes for bug 124042 landed there.
Assignee | ||
Comment 18•22 years ago
|
||
This patch removes incorporates beards changes, removes Darins additions, and eliminates dead project dependencies.
Reporter | ||
Comment 19•22 years ago
|
||
Comment on attachment 73280 [details] [diff] [review] Patch to fix MRJ Plugin and remove dependencies. sr=darin
Attachment #73280 -
Flags: superreview+
Assignee | ||
Comment 20•22 years ago
|
||
Same patch, except for the 0.9.9 branch.
Reporter | ||
Comment 21•22 years ago
|
||
Comment on attachment 73296 [details] [diff] [review] Patch for the 0.9.9 branch. sr=darin
Attachment #73296 -
Flags: superreview+
Comment 22•22 years ago
|
||
Comment on attachment 73280 [details] [diff] [review] Patch to fix MRJ Plugin and remove dependencies. r=beard
Attachment #73280 -
Flags: review+
Comment 23•22 years ago
|
||
Comment on attachment 73296 [details] [diff] [review] Patch for the 0.9.9 branch. r=beard
Attachment #73296 -
Flags: review+
Comment 24•22 years ago
|
||
Comment on attachment 73280 [details] [diff] [review] Patch to fix MRJ Plugin and remove dependencies. a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #73280 -
Flags: approval+
Comment 25•22 years ago
|
||
Comment on attachment 73296 [details] [diff] [review] Patch for the 0.9.9 branch. a=asa (on behalf of drivers) for checkin to the 0.9.9 branch
Attachment #73296 -
Flags: approval+
Assignee | ||
Comment 26•22 years ago
|
||
Fix checked into the trunk.
Assignee | ||
Comment 27•22 years ago
|
||
Not currently planned to land on the branch. closing as fixed (on trunk.)
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 29•22 years ago
|
||
I'm removing this release note item for this bug from the Mozilla 1.0 and future versions of the release notes because this bug is marked fixed. Mail me if you think this item should be re-added.
You need to log in
before you can comment on or make changes to this bug.
Description
•