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)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED INCOMPLETE
mozilla1.8beta1

People

(Reporter: timeless, Assigned: timeless)

Details

Attachments

(1 file)

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.
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
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.
> 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.
(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)
Comment on attachment 185791 [details] [diff] [review] switch to observer broadcast this code is from Cenzic Hailstorm 2.5-2.6
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?
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.
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 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-
i've already repeatedly explained why prefs don't work. please don't suggest that again.
(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.
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)?
s/superior/inferior/ ... you get my point? ;-) you seem to be making things harder for yourself.
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.
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?
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.
i spoke with biesi and believe that swapping the two urls should resolve the string issues.
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.
QA Contact: apis
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
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: