Closed Bug 572000 Opened 10 years ago Closed 9 years ago
Stub for Gopher redirecting to Overbite
Implementing in JS sounds better to be, all else being equal.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Working patch. However, I'm open to suggestions to implement it better. I was also considering adding a quick alert to tell people what is happening, unless this is not desirable.
You should point to a URL without the locale and app so AMO can autodetect: https://addons.mozilla.org/addon/7685/
URL corrected as advised.
Also, who would be the best one to ask to review this?
Unbitrotted for Fx 4.0b3pre. Also, I talked to Justin Hart and Robert Kaiser, and they suggested a friendlier interface, so this one pops a localizable prompter.
Unbitrotted. Gavin, would you be the right person to ask for a review (see bug 388195 for the justification)? If not, who would be appropriate?
Sorry, forgot the commit header.
Updated to current.
I'm temporarily moving this bug to Firefox as all the files the latest patch touches are in /browser/. But if this is put in /toolkit/ then SeaMonkey won't have to fork these files hopefully.
Status: NEW → ASSIGNED
Component: Networking → General
Product: Core → Firefox
QA Contact: networking → general
(In reply to comment #10) > I'm temporarily moving this bug to Firefox as all the files the latest patch > touches are in /browser/. But if this is put in /toolkit/ then SeaMonkey won't > have to fork these files hopefully. Is that preferable? I can certainly generate a second patch for that (or do so pending review of this one).
I see no real reason for this to live in /browser. Seems to me like this could live in netwerk/ and be usable by other gecko users.
So back to Core::Networking? Who would be a suitable peer to review this over there?
Assignee: nobody → spectre
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Version: unspecified → Trunk
This was based on Robert Sayre's suggestion in bug 388195 comment 126 (which I asked to work on, and this seemed okay at the time based on bug 388195 comment 135 -- please advise if I misunderstood). W/r/t the modal dialogue, I can rewrite it to use an XUL error page instead. Would that be acceptable?
(In reply to comment #16) > W/r/t the modal dialogue, I can rewrite it to use an XUL error page instead. That would definitely be much better than this approach if it's doable.
I couldn't get netError.xhtml to cooperate, so this is a different tack -- it uses notifications instead. If there is no notification box available, it falls back on NS_ERROR_UNKNOWN_PROTOCOL so that the default handlers are called. This version is also simpler and runs from netwerk/base/src. Boris, would you be the right one to ask for a review, or should I ask Darin or Jason?
Jason might be a better reviewer in terms of how this will work with e10s. If he wants me to take a look, though, I can. Darin's probably not a good choice; he is not really active anymore.
Attachment #469349 - Flags: review? → review?(jduell.mcbugs)
A couple small tweaks.
Do we want for FF4? Otherwise we have no "soft" transition for gopher:// If so, this needs to land soon--it has localization strings and UI interface change.
blocking2.0: --- → ?
Depends on: 388195
Attachment #471392 - Flags: feedback-
Strings altered/fixed as requested.
Attachment #472432 - Flags: review?(l10n) → feedback+
I put the Mozilla part on there to reassure the user that the site they were going to is a Mozilla site. Would just yanking the "now" be okay with you? Or is there a more standard way to express that the user is going to a Mozilla-maintained server?
Attachment #472432 - Flags: review?(jduell.mcbugs) → review+
Attachment #472432 - Flags: ui-review?(gavin.sharp) → review-
This is blocking2.0- per :bs' triage, so we shouldn't add it to the game anymore, IMHO.
Hold on. blocking- doesn't mean "won't take the patch if it's ready"...
I strongly advocate against pre-landing strings in any case. And for things that are non-blocking, even stronger. Comment 31 sounds like that'd only depend on ui-review, and I disagree.
Landing a complete XHTML page with DTD that can be redirected to by the protocol implementation handler doesn't seem like it would be particularly difficult for localizers to deal with. Much simpler than most other strings-only patches have have landed in the past. In any case, I was just mentioning that as one of the possible options. We can also just forget about this for 4.0, or get the whole thing done for b7. I don't really have any strong opinions either way.
Okay, I'll work up something with that approach. Would netError.xhtml be a good basis to model after? Also, where would the best place in the tree be to put it?
Before I get too deep in the weeds, let me make sure that this is the basic notion Gavin was talking about. This just redirects gopher:// to netError and (hopefully correctly) sets the principal as he advised. Is this an acceptable approach? Also, should I make a content/ area for netwerk/, or do I need to put the error page in docshell/ or toolkit/? I plan to base it on netError.xhtml, unless there's a way I can (ab)use netError itself to display a custom message -- I don't think I can from here, however.
I went ahead and created a content area for Necko, and put gopherAddon.xhtml in it. That will make it easier to remove being only in one module, since I know this stub will have a finite lifetime. This uses the redirection method Gavin suggested and has a small DTD for l10n.
Thanks for the spot; I just pulled the consts out entirely since they serve no purpose at this point. However, oncommand doesn't work within this context (in fact, netError.xhtml also uses onclick, not oncommand). onclick is the only event handler that functions for some reason. I'm not sure if that's a bug.
(In reply to comment #41) > However, oncommand doesn't work within this context (in fact, netError.xhtml > also uses onclick, not oncommand). onclick is the only event handler that > functions for some reason. I'm not sure if that's a bug. XHTML may not support it then. In XUL oncommand works and is the preferred event.
Attachment #481956 - Flags: review?(l10n) → feedback+
Okay. I'll normalize them all to say "URL" for consistency.
Attachment #481956 - Flags: ui-review?(gavin.sharp) → review?(gavin.sharp)
Attachment #481956 - Flags: ui-review?(beltzner)
Would it be possible for this to make beta 8?
I landed this in TenFourFox beta 11 in the meantime. To the SeaMonkey devs, do you want this for SeaMonkey even if it is not taken in Firefox? I can work up a SM patch simultaneously, although I suspect it probably will apply as is.
> To the SeaMonkey devs, do you want this for SeaMonkey even if it is not taken > in Firefox? I can work up a SM patch simultaneously, although I suspect it > probably will apply as is. Looking at the patch, it's all in core (mozilla-central/netwerk) which means it's in shared code. Land it there and we'll pick it up automatically. Of course it's possible to rewrite the patch to comm-central/suite but we'd rather not have forked code except as a last resort.
I'm going to call this WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
(In reply to comment #50) > We shipped Firefox 4 with Gopher removed and so far I haven't heard a peep - > I don't think we want/need to do this. My guess is that a population die-hard enough to still actually use Gopher is fine with just figuring out that they need an addon now themselves. Even if Firefox 4 managed to have gotten this, we'd probably be talking about removing it for Firefox 5 or 6 by now; we're definitely pass the window where this would've possibly been helpful. WONTFIX sounds good to me.
Another Gopher user here. I use SeaMonkey and just encountered gopher being removed in SeaMonkey version 2.1. I submitted bug 665708 since something just broke but it wasn't clear what happened. Is it possible to adapt this patch to SeaMonkey for bug 665708? Thanks.
You need to log in before you can comment on or make changes to this bug.