0

Imagine I have a public display, showing a browser displaying a web page.

Is it possible to send a GET or POST from a mobile device to an HTTP server which triggers some AJAX/pubsub/websocket JavaScript function that changes the page that is presently being viewed on the display, or even just changing an iframe's current domain?

Cross-domain pushstate? Is this at all possible even on your own setup?

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
sirvon
  • 2,547
  • 1
  • 31
  • 55

2 Answers2

2

You can do this with JavaScript on the client side. This is covered pretty well in that question: Updating address bar with new URL without hash or reloading the page

Unfortunately, it's a relatively new, and mostly unsupported feature. Your alternative is to set the hashtag and use it for navigation.

UPDATE:

If you are trying to "push" pages to the user like a TV channel, then you can have an AJAX request poll the server every few seconds to see if there's a new page. The server would respond with the new URL. You could then put that page in an iFrame.

Community
  • 1
  • 1
nicbou
  • 1,047
  • 11
  • 16
  • I don't think the OP's asking whether they can change what's in the browser's address bar without triggering a page reload. The OP seems to *want* to trigger a page reload: "...that changes the page that is presently being viewed on the display". – Paul D. Waite Apr 09 '13 at 13:31
  • Yes, I would like to change the entire browser display with another url something akin to tv. Your watching tv and the studio's change it for you, I want to enable changing the browser from the opposite side – sirvon Apr 09 '13 at 13:37
  • I really, really hesitated to mark it as poor quality. I read the question multiple times and still don't understand what OP is asking for. – nicbou Apr 09 '13 at 13:37
  • Yes, because the concept goes against convention of how we view the internet and browse the web – sirvon Apr 09 '13 at 13:38
  • 1
    I've updated my answer accordingly. That being said, conventions are there for a reason. Unless your idea is revolutionary, I doubt it will please your users. – nicbou Apr 09 '13 at 14:02
2

Assuming you control the web page being shown on the public display, yes.

The web page would need to either periodically contact the server via AJAX, or have a long-running connection to the server (i.e. Comet or WebSockets).

When the server receives the request from the mobile device, it either uses the Comet connection to send the new URL to the web page, or when the web page next contacts it via AJAX, it sends the new URL in response.

The web page then sets its own window.location property to this new URL.

Note that once it's done this, you'll no longer be able to send the browser in question to another new page, unless the page that you've just sent it to also includes the JavaScript that contacts your server.

But if you don't control the web page being displayed...

Then you'd need a browser extension to initiate the connection between the browser and your server.

Paul D. Waite
  • 96,640
  • 56
  • 199
  • 270
  • so pretty much it can't be as straight forward as send GET or POST, script accept variable from GET or POST and execute a command with that variable in this case a URL. – sirvon Apr 09 '13 at 13:34
  • 1
    @sirvonandrethomas: it's almost that straight forward. If the web page is polling via AJAX, the command on the server would be to write the URL to the place where it's read by the server code that responds to the AJAX poll. If the web page has a Comet/WebSockets connection, then I think it literally is that simple: the server code immediately sends the URL to the web page via the Comet/WebSocket connection (I believe: I've never worked with Comet or WebSockets). – Paul D. Waite Apr 09 '13 at 13:40
  • 1
    @sirvonandrethomas: I've re-edited your question to be a bit more focused on specifics, and I've edited my answer to a) mention WebSockets, which I'd forgotten, and b) include an assumption I made regarding the web page being displayed. You might want to re-read to see if my assumption is true. – Paul D. Waite Apr 09 '13 at 13:48
  • 2
    Instead of setting `window.location` you could simply change an iframe's `src` attribute. While using an iframe won't change your browser's address bar, it allows you to stay connected to the "master" server. – Bart Apr 09 '13 at 13:50
  • @Bart: ooh yes, that's true. – Paul D. Waite Apr 09 '13 at 13:51
  • 1
    yeah that's a good point about the new page taking away the javascript.. and that's an even excellent +1 in favor of an iframe solution – sirvon Apr 09 '13 at 13:56
  • 1
    OOOHHH OK!!! so in order for the server to keep some type of connection to the browser it needs have a hook to it,,, the webpage is the hook but if that departs the server can no longer talk to the browser... so an extension keeps the browser and the server talking OR – sirvon Apr 09 '13 at 13:57
  • only webpages that included this special script would keep the server with a connection the browser – sirvon Apr 09 '13 at 14:00
  • @sirvonandrethomas: precisely (hence why Bart's iframe idea sounds like the best fit for your "browser remote control" idea). HTTP doesn't maintain a connection with the server after the response has come back. (Which, for a protocol that's meant to work at worldwide scale, makes sense.) – Paul D. Waite Apr 09 '13 at 14:13