Closed
Bug 244991
Opened 21 years ago
Closed 9 years ago
Add an option not to build link prefetching
Categories
(Core Graveyard :: Embedding: APIs, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
mozilla1.8beta1
People
(Reporter: timeless, Assigned: timeless)
Details
Attachments
(1 file)
7.12 KB,
patch
|
darin.moz
:
review-
|
Details | Diff | Splinter Review |
Link prefetching is interacting badly with our product. I could disable it by
changing to default preferences to not use it, but then any profiles i have
which are set not to use it will be hosed (they'd forget the setting when
transitioning to the disabled version, and then use the default settings which
on normal builds would be enable).
I'd like a --disable-prefetch flag that we can pass to configure.
Comment 1•21 years ago
|
||
timeless, are you going to attach a patch?
Building deps for nsContentSink.cpp
nsContentSink.cpp
...\mozilla\content\base\src\nsContentSink.cpp(49) : fatal
error C
1083: Cannot open include file: 'nsCPrefetchService.h': No such file or
directory
These depenendencies aren't nice. I should not have to hack the tree in order to
disable this thing.
Severity: normal → major
Target Milestone: --- → mozilla1.8beta
Comment 3•21 years ago
|
||
timeless: how is link prefetching interfering with your product? are you using
<link rel="next" href="..."> tags? moreover, why don't you just disable link
prefetching via prefs?
network.prefetch-next = false
please read comment 0. i clearly indicated why i can't use the preference junk.
as for how it adversely affects our commercial product:
we don't control the content we encounter. but we are at its mercy. we promise
to act like a normal <insert your http application here>, and do our best.
then link prefetch comes along, spies a url and goes to grab it. it introduces
itself to the server as mozilla, passes mozilla cookies and credentials along
and borks session state.
i'm not sure i'm going to attach the patch. i might see about getting someone
else to replace the code with an observer service broadcast.
Comment 5•21 years ago
|
||
> I'd like a --disable-prefetch flag that we can pass to configure.
what's the difference between this and changing the value of the pref in all.js?
if you control the build why not change the default value of the pref?
comment #0 only seems to explain why a setting is prefs.js would not work.
no, that's why a setting in all.js will not work, it'll hose me when i switch
to a normal mozilla build which doesn't have that all.js setting.
Comment 7•21 years ago
|
||
(In reply to comment #6)
> no, that's why a setting in all.js will not work, it'll hose me when i switch
> to a normal mozilla build which doesn't have that all.js setting.
if you don't control the build, because you need to use a normal mozilla build
(i'm assuming you mean one from mozilla.org), then how does --disable-prefetch
help you? i'm not understanding something... please clarify the constraints here.
in my builds, i'll use the flag, but in mozilla.org builds i'll set the pref.
that pairing doesn't trip on anything.
Assignee: adamlock → timeless
Status: NEW → ASSIGNED
Attachment #185791 -
Flags: superreview?(darin)
Attachment #185791 -
Flags: review?(darin)
Assignee | ||
Comment 10•20 years ago
|
||
Comment on attachment 185791 [details] [diff] [review]
switch to observer broadcast
this code is from Cenzic Hailstorm 2.5-2.6
Comment 11•20 years ago
|
||
I don't understand the benefits of using the observer service here. Please
enlighten me. What's wrong with just making it so that do_GetService for the
prefetch service returns null?
Assignee | ||
Comment 12•20 years ago
|
||
using observer service means i don't have to build the stupid interface. i _do_
not build the directory. it makes the code more flexible.
Comment 13•20 years ago
|
||
What's wrong with building the interface? Using the observer service means that
you have to convert the URL from nsIURI -> string -> nsIURI (plus some charset
conversions in the middle). It seems overkill when XPCOM already gives you
support for optionally implemented components.
Comment 14•20 years ago
|
||
Comment on attachment 185791 [details] [diff] [review]
switch to observer broadcast
I think it would be better to solve this problem using changes to the build
configuration, or how about changing the value of network.prefetch-next in
all.js? That file is preprocessed, so it should be trivial to add an #ifdef to
that file.
Attachment #185791 -
Flags: superreview?(darin)
Attachment #185791 -
Flags: review?(darin)
Attachment #185791 -
Flags: review-
Assignee | ||
Comment 15•20 years ago
|
||
i've already repeatedly explained why prefs don't work. please don't suggest
that again.
Comment 16•20 years ago
|
||
(In reply to comment #8)
> in my builds, i'll use the flag, but in mozilla.org builds i'll set the pref.
> that pairing doesn't trip on anything.
So, why don't you change the default value of the pref in your builds? You
haven't explained why that doesn't work.
Comment 17•20 years ago
|
||
Bottom line: if you are already able to change anything about your builds, but
can't change the mozilla.org builds, then why is one way of disabling
prefetching (default pref change) in your build superior to another (removing code)?
Comment 18•20 years ago
|
||
s/superior/inferior/ ... you get my point? ;-)
you seem to be making things harder for yourself.
Assignee | ||
Comment 19•20 years ago
|
||
i have repeatedly explained that any user pref set to the same value as a
default pref is destroyed by libpref when you exit. this is a feature. as such,
if mozilla.org builds have boolean pref value false in a default file, and my
builds have it set to true in a default file, successively running any profile
through these two builds will result in the pref not being stored in prefs.js.
i use offical mozilla.org nightlies, my own cvs builds of mozilla and my
commercial builds. now i could write a script which hacks mozilla.org nightlies,
but then they wouldn't be standard nightlies, and if i follow the general
"create a new profile" advice, i still wouldn't have default behavior which
would be *very* bad.
Comment 20•20 years ago
|
||
Ah, that old problem. I did not see that explained anywhere in this bug report
(maybe we discussed it over IRC, but I forgot the connection to this bug). At
any rate, why nsIObserver? Why not just hack the build to not compile and link
nsPrefetchService.cpp?
Assignee | ||
Comment 21•20 years ago
|
||
having to repeatedly describe that old problem in every bug i file relating to
prefs gets really old. and i know that i've informed the people in this bug (as
you admit) about it.
as to observer, why should we bloat the system with another interface? it
doesn't serve any purpose, it does make vtables bigger, it means more silly
things to build, why should i have to pay for an interface that i'm not
building? note that even in the existing code, the object already implements
nsIObserver. to make the patch simple (for review and so that i could get it
into cvs and have less chances of merge conflicts) i didn't inline the methods
it calls, but we certainly could do that.
why is it that I can never get people to do things which the firefox/toolkit
people are able to get people to do? they're able to get interfaces killed when
they feel like it.
Assignee | ||
Comment 22•20 years ago
|
||
i spoke with biesi and believe that swapping the two urls should resolve the
string issues.
Comment 23•20 years ago
|
||
timeless: Are you arguing that the cost of nsIPrefetchService is significant? I
don't buy that at all. Having the HTMLContentSink poke nsIPrefetchService if an
implementation exists seems like a perfectly reasonable use of COM. I don't see
why you need to broadcast the link tag information. It sounds to me that you
just don't want to have to write a different patch.
Updated•15 years ago
|
QA Contact: apis
Comment 24•9 years ago
|
||
Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•