Closed
Bug 1286076
Opened 9 years ago
Closed 6 years ago
Redirect MXR to DXR
Categories
(Webtools Graveyard :: MXR, defect)
Webtools Graveyard
MXR
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: erahm, Unassigned)
References
Details
Per discussion on dev-platform [1] folks would like to see MXR redirect to DXR rather than just present an outage page.
Options proposed:
- Just link to DXR
- Redirect to DXR
- Fancy redirect that will go to roughly the equivalent page / location on DXR
[1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/_k-ditFrne4
Comment 1•9 years ago
|
||
Current plan is twofold:
1. create an interstitial page that informs about MXR being decommissioned and provides a best guess link to DXR.
2. redirect MXR links in Bugzilla directly to DXR (no #1 in this case)
We should probably have bugs on file for both #1 and #2. Not sure that we yet do.
fubar - Do you know if we have bugs on file?
Flags: needinfo?(klibby)
Comment 2•9 years ago
|
||
Is it possible to display the outage page in place instead of redirecting to the fixed URL until this bug is fixed?
Currently I have to back > copy link location > paste > edit url to go to the corresponding DXR url. This is very annoying.
Comment 3•9 years ago
|
||
(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #1)
> Current plan is twofold:
>
> 1. create an interstitial page that informs about MXR being decommissioned
> and provides a best guess link to DXR.
Do we really need an interstitial? Can we signal dxr when a link came from an mxr redirect? And then let dxr put a dismissable warning at the top of the page communicating that mxr is decommissioned, and folks should use dxr directly?
Comment 4•9 years ago
|
||
The use case for the interstitial page is not users following links from BMO/MDN, or searching via their browser/mach. We would like to have those cases transparently redirected (eg bug 1285657), but until then even an interstitial is better than the current hardhat.
The real use case is that there are untold numbers of 3rd party sites whose code is actively pulling data/code from mxr. The effective_tld_names.dat file was by far the largest (>5m/day), but isn't the only thing by far. We want to actively discourage the hotlinking, but provide a mechanism for users/maintainers to discover why their code may be broken and what to do to fix it.
Flags: needinfo?(klibby)
Comment 5•9 years ago
|
||
(In reply to Kendall Libby [:fubar] from comment #4)
> The use case for the interstitial page is not users following links from
> BMO/MDN, or searching via their browser/mach. We would like to have those
> cases transparently redirected (eg bug 1285657), but until then even an
> interstitial is better than the current hardhat.
>
> The real use case is that there are untold numbers of 3rd party sites whose
> code is actively pulling data/code from mxr. The effective_tld_names.dat
> file was by far the largest (>5m/day), but isn't the only thing by far. We
> want to actively discourage the hotlinking, but provide a mechanism for
> users/maintainers to discover why their code may be broken and what to do to
> fix it.
Why discourage the hotlinking? Why do we need to break their code?
Have you considered making DXR's URL syntax conform with the MXR's URL syntax? The differences seem subtle and I wonder if they're justified, given the implied cost. Because ideally, I think we'd just keep the MXR sub-domain alive as a simple alias to the new one. No fancy rewriting of URLs, no interstitial page that ends up annoying users even if those users aren't mozilla devs because we're also rewriting URLs in BMO and MDN. It's still not clear to me why things need to be this complicated.
Comment 6•6 years ago
|
||
mxr is gone, mass closing.
https://searchfox.org/ is a much better alternative.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Updated•6 years ago
|
Product: Webtools → Webtools Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•