Status

P3
normal
RESOLVED INVALID
20 years ago
8 years ago

People

(Reporter: bruce, Assigned: pavlov)

Tracking

Trunk
Future

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
mozilla/gfx/src/nsImageURL.cpp calls a netlib functions directly. (NS_NewURL())
and mozilla/gfx/src/nsImageNetContextAsync.cpp calls NS_OpenURL().  This link
type dependency isn't so great.  Means that test apps like scribble and widget
which only need GFX and Widget need to drag in a lot of extra stuff.

Updated

20 years ago
Assignee: brendan → warren

Comment 1

20 years ago
Warren, I'm hoping you'll take this, per our destroy-all-NS_-monsters sub-item
under "XPCOM binary compatibility" architecture action item.  If not, pls.
bounce it back to me.

/be

Updated

20 years ago
Assignee: warren → brendan

Comment 2

20 years ago
2 issues here: (1) should gfx depend on netlib or not (by whatever means), and
(2) are NS_ functions really all that evil.

1. Perhaps gfx can be changed so that critical methods take nsIInputStreams and
nsIOutputStreams instead of URLs and calling NS_OpenURL -- force the caller to
do the opening. The owner of gfx should decide whether that's a good thing or
not. However, given that necko is much smaller than netlib, maybe the real
reason for wanting to remove the dependency (footprint) goes away.

2. We made an attempt in necko to not define NS_ functions, forcing callers to
go through the nsIIOService to do things, but as we attempted to land we built a
compatibility library because it was so inconvenient to use the service manager
to do all the linkage. We did one thing differently however -- we made the
compatibility library a static lib that links with the callers DLL (doing the
service manager thing internally), thereby avoiding exported functions from
necko.dll and the whole ordinal problem on Windows.

However, after doing this, it struck me that we just built our own version of an
import library, and a pretty inefficient one at that. We would have been a whole
lot better off had we just put the NS_ functions in necko, and provided a .def
file to fix the ordinal problem.

It is not my (and Rick Potts) recommendation that we just provide .def files for
all the libraries that define global entry points. If we ever want to evolve the
service interfaces in the future, we'll still have to support the old
service interface and provide these NS_ functions for backward compatibility
anyway.

Updated

20 years ago
Target Milestone: M9

Updated

20 years ago
Status: NEW → ASSIGNED

Updated

20 years ago
Target Milestone: M9 → M10

Comment 3

20 years ago
This should be easy, but it shouldn't hold up M9 either.

/be

Updated

19 years ago
Target Milestone: M10 → M14
Pushing out, not a beta blocker.

/be
Target Milestone: M14 → M16
Move out past nsbeta2.

/be
Target Milestone: M16 → M18
Moving out, milestone 20 will become a better Mozilla milestone soon.

/be
Target Milestone: M18 → M20

Updated

18 years ago
Target Milestone: M20 → mozilla1.0
I sat on this for months, but pavlov may actually be fixing it right now, for
all I know and hope.

/be
Assignee: brendan → pavlov
Status: ASSIGNED → NEW
(Assignee)

Comment 8

18 years ago
yes, this dependancy will go away.

Comment 9

17 years ago
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 10

15 years ago
retargeting
Target Milestone: mozilla1.0.1 → Future

Updated

14 years ago
Component: XP Miscellany → GFX
Product: Core → Core Graveyard
I don't think this code exists anymore.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.