I'm trying to trigger the "Desktop site" (and additionally know if it's already triggered) you can have on your mobile browser from JavaScript, is there a way to do that?
I saw some others topics that had the same issues but on their sides they were more about having a custom view for both or something along this way, while on my side I would just want to trigger this specific feature
(this is a comment, but its a bit long)
Upvoted here because although you are asking the wrong question, what sits behind that question is an interesting problem and not well documented.
The menu entry asserts some behaviour which is sent to the backend server. The backend server then delivers different content. For security reasons, a web page can interact with browser chrome (i.e. the furniture outside the view of the website in the window). So the answer to the question you asked, is that you cannot invoke this from javascript. However your problem is not invoking a menu item but rather creating the same effect as invoking the menu item.
Providing a toggle to change the presentation layer on the website is straightforward, however the question should really be,
How does this menu option change the behaviour of the site?
How to implement/integrate a parallel mechanism for achieving the same result.
Related
A common question I've seen is "How do you detect if a user is leaving a web page?". I've reviewed the answers for almost all of these questions, but they often don't provide visibility into the initiator of that redirect.
I'm trying to tell from a Chrome extension where if a tab changes pages:
Did the user use the address bar to change pages?
Did javascript on the web page cause the page change?
Did the user interact with an HTML component which caused the page change (i.e form or anchor)?
Did the user simply close the tab?
I might be missing some other variations, feel free to include additional ones in your answer. What I'm really after is: "Was the page change intended by the website, or did the user arbitrarily change the page?".
Some of the questions I listed are not directly possible. For example, my first question about if the address bar changed has been addressed before with no solution. A valid solution to this would be through process of elimination. If you could prove that question #2-#4 were not the case, then it would only leave #1 as the option.
#2 is another interesting one because there are many ways to change the page through javascript. You could set window.location.href, you could use window.navigate, you could use window.history.* (back, go), etc. Chrome DevTools is able to trace back most javascript redirects though, maybe that's an angle.
#3 similar to the problems with #2, there are problems with the number of elements that can cause page changes. Also, any solution would need to work with dynamically generated content as well (i.e $([some selector]).on(...).
#4 is solvable via Chrome's tabs API.
If you have cross-browser approaches, that'd be a plus. Thanks.
I'm currently developing a Chrome Web App using the Chrome Platform APIs and Javascript and I simply can't find a way to display a prompt() dialog to ask the user for a value, in a way that prevents him from clicking anywhere else until he enters a value and accepts or cancels (meaning, EXACTLY how it works with Javascript).
My problem is, I just can't find a way to do this with the Chrome Platform APIs (note that prompt(), alert() and confirm() can't be used in packaged apps). I already checked questions similar to mine and they all point to the Google App Script documentation, which doesn't work for Chrome Apps.
The only "solution" that I've really found is making a new window, enabling singleton so that it can only be an instance of it and displaying a form there, getting the value when the user accepts(I haven't really finished that last part, I need a way to check when the window is being closed by a button). Still, this is kind of a lot for a simple dialog.
Is there a simple way to do this that I'm missing or is the "intended" way to do this to use multiple windows?
window.prompt has two features:
It requests input from the user.
It does this in a synchronous way, i.e. execution of JavaScript in your page is suspended until prompt() returns.
The first feature can be emulated, but the second feature cannot. So, you will be able to get user input, but only in an asynchronous way. There are two ways to prompt the user for input:
In a popup.
In a lightbox.
A lightbox is similar to a popup, except that it's embedded in the page itself. All implementations of a lightbox involve at least two containers:
A div that covers the whole page, so that the user cannot click on anything else. (CSS: position:fixed;top:0;left:0;width:100%;height:100%;z-index:1000;)
Other HTML elements that together resemble a dialog (input fields, buttons).
There are plenty of existing UI libraries to show an inline dialog, e.g. jQuery UI.
I have also asked this question here at the chromium Google group.
I would like to be able to keep a context menu open even after a user checks, or unchecks, a checkbox. My plugin allows users to check which devices they are using when testing and when testing multiple devices, it is frustrating to open the context menu several times to tick each device.
Does anyone know of a way to do this? It does not seem to be supported natively. I don't really want to use some magic to re-open the menu, if possible, after a user checks a given device, hence the question here. If it is the best (yet hacky) way, then fair enough. I hope it's not! I think menu flickering would also look bad.
No, there is nothing in the API to allow that.
It might be an interesting feature request - if you're willing to spend time to formulate it at https://crbug.com/
I have a single-page mobile application developed with Backbone and Zepto.
It works correctly with the back/forward buttons in the browser.
When the user navigates to a page, the new content slides in from the right as the old contents slides away to the left (and out of the viewport). I want the same thing to happen if the user presses the "forward" browser button. This all works.
I've got a class that I add to the body element navigate-back that will flip this behaviour, so when the user navigates back with the browser's back button, they see the content sliding back in from the left and the other content sliding into the right. Basically just the opposite of going forward.
I need to detect if the user is navigating backwards so I can invoke the alternate behaviour. I have tried implementing my own history stack, but I've ran into lots of problems where sometimes it marks a forward as a back navigation which ruins the visual cue. It's descended into a kludge of hacks now and probably would only embarrass me if I posted it.
What is the best way to implement my own history stack so I can detect if the user is navigating forward/back in the context of a single-page Backbone mobile application?
I don't know about backbone.js1, but I have helped develop a mobile application which had to implement exactly this behavior in html5, so I should be able go give some good advice:
First of all it's good to know that the history.pushState function exists. The big problem with it though is that it is supported up to android 2.3, but not on android 3 till android 4.0.3. As kiranvj points out correctly this can be solved by using the popular history.js library which provides a polyfill solution for the lack of the history functionality.
Now, getting to your actual problem, the way I implemented the history direction animations was by adding data to the pushState function ( history.pushState(data,title,url) ) with which I identified the logical position of the page. In my application I wasn't only limited to a horizontal bar, but in your case you would keep track of position where any new loaded page get's a position which is one higher then your current page. E.g.
History.pushState({position:History.getState().data.position+1},"Your title","Your URL");
Next, when the window.onstatechange or window.onanchorchange event triggers you observe whether the position is higher or lower than your current page (e.g. by using the history.js History.getState() function which I used above) and depending on this you decide in which direction to move (lower is to the left, and higher is to the right), as is illustrated by the image below:
You will also note that I already assumed on the first page that you have {position:1}, whereas normally the first page will have no state information. The way this can be achieved is by using history.replaceState which replaces the current empty state with a more informative state. Alternatively you can also check for an empty state on any of the previously mentioned events and if it's empty you assume it to be the left most one ({position:1}).
Hope this helps and if you have any additional questions feel free to ask.
Please note that this answer assumes you are using history.js and you would need to listen to slightly different events (such as onpopstate) and use slightly different structures (history rather than History) if you would want to build your own solution.
It is also useful to note that it is possible to build this with your own queue array which gives you a lot more control, but will not work in combination with the browser's back button. This is a big issue with browser sites, however is far easier in case you are building a cordova (a.k.a. phonegap) web application.
1 Just read about it and it appears to do some history handling of its own, which might make it more complex to integrate the technique described above.
If you're working on a true single-page app, why not you set up an array to hold history urls in a js variable (as opposed to relying on something like history.pushState and its support)?
Whenever a new page is navigated to, you can push its url into the array, whenever a "back" button is pressed, you can retrieve the url needed as far back as you want. This will work perfectly as long as you correctly discard urls when the user goes back a few steps and then navigates to a new link.
I've never tried implementing this to be used for page history, but this worked perfectly well for in-page undo-redo logic.
Update:
After further research, the approach above would not work for a page reload as it would be an action occuring outside of history handling available through JS. It would still work for tracking back/forward transitions, but such history will be lost on navigating to a url external to the app or a page refresh. David Mulder's answer seems to lack this limitation by relying on browser-level history that persists outside of the page scope.
I had the same issue when working with Zepto on mobile with single page - multiple views.
Initially I used html5 statechange and onhashchange. It all have some issues in one or other mobile device. Finally I used Zepto history plugin from here https://github.com/browserstate/history.js
It somewhat solved most of the issues. Try it, it will be useful, it handle html4 and html5 features wherever possible.
Use this thing in single page mobile application this will allow to the history and move the user to back.
function onBackKeyDown() {
history.go(-1);
navigator.app.backHistory();
}
Sammy.js's v.6.x branch (the one that relies just on hash changes) is a perfect, simplest, most browser-compatible approach to tracking history. There, history is not tracked at all, as Sammy just watches for hashchange.
Relying on "#/slide/123" allows you to support hard page reloads, and simplifies the work
Peel off the last part (slide number) on each page view, push into global. On new route, see if number is more or less than what is stored in global and do the correct (left or right) animation. If global is undefined, no animation.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Disable browser's back button
Is there any way to disable browser(specifically IE) BACK button, FORWARD button, REFRESH button by javascript. So that, when ever any user will click on any button nothing will happen.
No, you cannot reliably, reasonably do that. Even IE's "kiosk mode" allows back, forward, and refresh (via keyboard shortcuts).
On an actual web page (a real page out on the web), disabling back/forward/refresh would of course be extremely inappropriate behavior and I assume that's not what you're trying to do. (Instead, use history libraries and such to ensure your page/web app actually works with the back and forward buttons to do what the user expects.)
Mind you, if you provide a link that opens a new window (which will probably actually end up being a new tab in most modern browsers), your page will be the first page in that window's history and so the Back button will automatically be disabled. And if your page doesn't offer any links anywhere else, it'll stay that way. And if the user hasn't gone Back, by definition they can't go Forward. Nothing you can do about Refresh, though.
If you have a genuine reason for actually disabling those actions (some kind of intranet application, that sort of thing), you'll probably have to distribute an actual application (for instance, .Net app via No Touch Deployment or similar) that incorporates a web browser control, which gives you the HTML/CSS/JavaScript environment but with dramatically higher control over that environment.
As far as I know, you can't modify the buttons in a browser with scripts.
Since you're working with IE, you may be able to use either VBScript or JScript, but I doubt you'll be able to disable the reload button.
More reading:
http://www.webdeveloper.com/forum/showthread.php?t=62177