Implementing in JS sounds better to be, all else being equal.
You should point to a URL without the locale and app so AMO can autodetect: https://addons.mozilla.org/addon/7685/
Also, who would be the best one to ask to review this?
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.
(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?
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.
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.
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.
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?
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?
Created attachment 481149 [details] Feedback: channel approach 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.
(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.
Okay. I'll normalize them all to say "URL" for consistency.
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.
(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.