Overlay URLs do not gracefully fail [#870546]

To reproduce:

1. Disable overlay

2. Put an overlay URL like http://localhost/drupal7/#overlay=admin/modules in the browser address bar and press return

3. You will arrive at http://localhost/drupal7, when your clear intent is to arrive at http://localhost/drupal7/admin/modules

Since we know have two parallel URL spaces, it's important that mapping from one to the other be clean. Otherwise, URLs will break when interchanged via email, in documentation, or in posts.

Comments

Comment #1

casey CreditAttribution: casey commented 6 August 2010 at 13:34

As David_Rothstein suggested on redirecting overlay-style URLs in #663660: Is it a good idea to have two different types of URL for many administration functions in core?:

I think it is not hard for core to automatically redirect URLs like http://localhost/drupal7/#overlay=admin/config/modules to http://localhost/drupal7/admin/config/modules in the case where the overlay module is not enabled. That redirect won't work if JavaScript is disabled, though, which I guess would cause problems if this stuff is ever getting indexed by search engines - however, these aren't the types of pages that tend to be.

Also, ideally we would not special-case the overlay here; there would be a more general fragment name (something like #display rather than #overlay) that any module could use, and some kind of method for modules to tell Drupal that they want to actually use it - the overlay module being just one example. If no module claims it, Drupal would redirect to the canonical URL.

Problem is that the URL fragment is never sent to the server. Thus the only option to get this done would be a client-side one; Javascript. But that would mean we need to add that Javascript to any page. I don't really like that as that would be the first unconditionally added Javascript (without overlay being enabled).

Comment #2

shunting CreditAttribution: shunting commented 27 August 2010 at 01:17

Then we have a broken system, in that URLs cannot be transparently interchanged between users. As I wrote:

Since we know have two parallel URL spaces, it's important that mapping from one to the other be clean. Otherwise, URLs will break when interchanged via email, in documentation, or in posts.

That's especially unfortunate for a content management system and one, moreover, that was designed to be RESTful.

UPDATE I looked at the definition of critical bug, and there doesn't seem to be a case for bugs that render the system more difficult to use for people outside the the system ("email," "documentation"). Surely, however, the process of simply grabbing a URL off the browser's address bar and pasting it into content is ubiquitous. This bug makes that process problematic, every single time, because recipients can't trust that URLs they get will work.

Is that "normal"? I don't know. Is that "critical"? Not by the definition. Not to go all meta, but this problem seems to be identical with the problem of "negative externalities," where the system exports all its problems to the surrounding eco system....

Comment #3

jcisio CreditAttribution: jcisio commented 4 February 2011 at 10:45

Version:

7.0-alpha6

» 7.x-dev

I think we can put this JS in drupal.js, not necessary in overlay module. About changing the name "overlay" to anything else (display? page?...), is it really necessary?

Comment #4

Damien Tournoud CreditAttribution: Damien Tournoud commented 4 February 2011 at 10:54

Version:

7.x-dev

» 8.x-dev

Because this requires to change the URL scheme of the overlay, it's too late for Drupal 7.

Comment #5

casey CreditAttribution: casey commented 4 February 2011 at 11:17

@jcisio or something like #885690: Reverse the overlay implementation (put the parent page in an iframe underneath the administrative page)

Comment #6

jcisio CreditAttribution: jcisio commented 4 February 2011 at 13:04

Version:

8.x-dev

» 7.x-dev

No, we don't need to change any in the URL scheme (as I suggested that such change is not necessary). This is a bug, and needs a simple fix (a new small JS code into drupal.js).

Comment #7

Damien Tournoud CreditAttribution: Damien Tournoud commented 4 February 2011 at 13:46

Version:

7.x-dev

» 8.x-dev

Nope, we are not putting overlay-specific code in drupal.js.

Comment #8

shunting CreditAttribution: shunting commented 12 February 2011 at 17:14

more on related issues. See also Tim Bray. (This is not a syntactic -- "hash bang" -- issue. It's an issue of how and where and whether Drupal remains RESTful.) Bray writes:

Contracts · Before events took this bad turn, the contract represented by a link was simple: “Here’s a string, send it off to a server and the server will figure out what it identifies and send you back a representation.” Now it’s along the lines of: “Here’s a string, save the hashbang, send the rest to the server, and rely on being able to run the code the server sends you to use the hashbang to generate the representation.” ¶

Do I need to explain why this is less robust and flexible? This is what we call “tight coupling” and I thought that anyone with a Computer Science degree ought to have been taught to avoid it.

We aren't doing this quite because we have two supposedly independent contracts, one of which is supposed to be a fallback for the other. Unfortunately, because the fail is not graceful, the contract is broken.