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.
Related
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.
I am working on an application that asks individuals to paste links to their social media and other relevant sites as part of the setup process. These later get turned into links on a compiled HTML page.
We are seeing a user issue that is arduous to deal with. When setting up the account on mobile, individuals do not understand that they need the website link to these various places, they try and open the target sites app instead (Facebook as an example), or they stare blankly unsure of what to put in the box or how to proceed.
I'm looking for a solution to this conundrum to help people achieve their ultimate end goal of putting the link on the resultant page.
I tried an iframe approach, whereby the thought was to load the target site, allow the user to navigate to the desired page, and hit a done button. Obviously this approach ran into several road blocks due to security restrictions and frame busting implemented by the various sites.
What would be great would be something like the file input, but for websites instead. We have the "URL" input; however, that only checks the URL for validity, I'm more interested in an approach that would open something akin to the file dialog, that would allow a user to navigate to a site and hit "done"
I've not been able to find anything that comes close. I'm seeing if someone knows something I do not, or has an idea I haven't yet tried. Ultimately, I'm trying to make it easy for an average consumer to choose the target for a link. (I'm fully aware how easy it is to open a browser tab and copy the link, I am truly supporting consumers who find that somewhat difficult / confusing)
Thank you for your time and consideration
I am looking for a way to improve the workflow in a PHP based CMS. There is a lot of switching between the editor mode and the preview mode of the page. The editor mode is huge to load, and so I would like to open the preview mode in a different window.
I don't want to use new windows or an iframe within the current window to keep the workflow simple and to avoid confusion.
Is there a way to explicitly open a new tab (not window), and to jump to that tab from a document, in Firefox? The number of users is limited, so there is the possibility to set up the client with the necessary extensions / permissions.
I know Firefox can be forced to open all links in tabs, but I think that won't cut it, as I still can't address and focus the newly opened window.
Thanks for all the great answers everyone. I have now enough material to decide whether I'll take the greasemonkey approach, rely on the user to set up "open in tabs" and address the window by name, or use a "inline" HTML solution as so many of you suggested. I am accepting the answer that I feel went most effort into.
There is no way to force a window to open as a tab. It's all dependent on the user's preference settings.
I second the answers that say you should do this in HTML using Javascript. Then it can work in all browsers that support JS.
I would put two divs on the page and show/hide each div depending on which tab is selected. If you are clever about this you could trap the click on the tab and determine if the user left-clicked or middle-clicked. If they left click you load that tab on the page. If they middle-click you let the browser open a new tab/window (according to the user's prefs, don't try to force it), and leave the current window unchanged (that is, don't switch to the new tab). The action for clicking on the tab would be to use AJAX to load the contents of the remote document and put it into the tab. Use Javascript to modify the URL before submitting the AJAX request so that the server knows to send a web page fragment instead of the whole page.
The advantage of this dual-natured solution is that the tabbed approach will work the way you want it to work for the majority of cases, but for users with, say, two screens, or who prefer switching between browser tabs, they will still have the flexibility to work in multi-window mode. This can all be done without any browser extensions and it should work equally well in IE as well as Firefox, Opera, etc. Avoid locking yourself into one browser, even one as excellent as Firefox. One day a customer will need to use Opera or Safari and you'll be stuck.
You say you don't want to use an iframe to avoid confusion. Now I don't know about the layout of your website, but I've been using the approach that the editor opens in its own div right next to the content being edited and the content is being live updated as you edit. No need to change tabs.
(If the window is too narrow there are HTML tabs Edit and Preview)
It does not seem to add confusion to the user and for me this approach works really well. Maybe it's worth considering in your case.
What about using iframes and JavaScript?
I know you said you want to avoid 'confusion using iframes', but in my opinion if you really need to load different pages at the same time this is the best option.
In theory, you could create your own tab system using javascript or even better, using jQuery, because its UI module offers pretty cool tab control.
For every tab you could load separate "headerless-footerless" version of your specific admin page inside <iframe> element. If user wanted to modify something different, he will simply click on the tab and bring different iframe.
All this could also be done using AJAX, but iframe solution is quite easy as you just need to load ready page and all postbacks are already handled by original page and separated from master-admin-page.
You might also need to play a little bit to set correct height of your iframe to fit all the content without scrollbars, but this again, is just bit of javascript.
Nope, there's no way to force the opening of a new tab, simply because this would be unsupported by un-tabbed browsing
You can only set it to open a new window, not a new tab.
Greasemonkey springs to mind - a quick google gives open in tabs on left click. I think you could modify that so it only runs on one particular page, and you'd be up up and away.
This question made me wonder if HTML 5 allows that sort of specification, and it doesn't (nothing in one of the other hyperlink attributes, either). A new browsing context is a new browsing context, there's no way to express a preference for tab over window or foreground over background.
You can't force a tab, but if you use a target with a specific name, like target="my_cms_window", many browsers will open this as a new tab. Additionally, they will remember the name and if you use the target repeatedly, put the contents in the same tab. I have found that this works pretty well in the real world.
If I go to this page and then delete the url from my browser's address bar, and then enter
javascript:document.getElementById('rsidebar').value='dsf';
The whole part refreshes. How can I prevent a page from refreshing when executing javascript from the address bar?
Also, are there any other techniques to manipulate a page without having access to the page source like the above method?
No, you cannot stop the user from manipulating the DOM.
You don't need to worry about people manipulating the DOM from the client-side. These changes only effect their local experience. They aren't actually affecting your site for other users.
You can easily manipulate the DOM using tools like Firebug, IEDeveloperToolbar, or Greasemonkey (Javascript engine).
When you do javascript:stuff(); and stuff() produces a return value, the whole page is replaced by it. You can prevent that by using javascript:void(stuff()); or javascript:stuff();void(0);
Already answered by others :)
For Q1: I think this isn't possible because the browser runs every website in its own 'sandbox'
For Q2: I believe Firebug will let you execute javascript on any webpage...
Question 1: As the earlier responders said, nothing you can do I don't think.
Question 2: Check out bookmarklets, some very cool things can be done by running your own JavaScript against pages from various sites. People have written bookmarklets to highlight things on the page, put warning indicators next to links that will open in a new window, or go to aPDF, etc.
I've created a tool that is used with a fairly popular music retailer.
The tool provides an enhanced search feature (transparent last.fm results, no ads, no lameness, nothing creepy) and I've found the most useful and unobtrusive way to display the search is as a toolbar using the much maligned iframe. This allows users to load search without stealing the users focus.
Not being a particularly big fan of iframes I thought it would be trivial to add a “close this frame” (ala Google image search) link allowing users to quickly and easily regain control of their browser.
However unlike google, I doen't know what the location of the content in the iframe is (only where it started, via src).
So now I find myself in world of XSS and all the security related concerns.
Using Javascript I've added 'back' and 'forward' buttons with the history object called from links in the parent (when a user does a search the results load into the iframe, so the back button allows them to go back to the primary site after their done using/perusing the search results).
Is there any way to call the current location within the iframe and reload the page (now sans frames) to that location?
I've checked PHP $GLOBAL/$_SERVER variables to see I might get lucky. I understand that there are security concerns, but I don't see how this particular function would be any different then history.back() where the browser makes the call itself without 'notifying' my parent frame.
I know I can retrieve the src location from the iframe itself, but of course that presumes the user doesn't navigate beyond this page, and if they do they don't mind losing their current location and being redirected back to page called initially by the frame (...ah...).
It almost seems like frames are designed to steal windows with no means for gracefully 'breaking out' and preserving integrity of the users session.
No wonder people hate them. :)
On Google image search when you remove the frame it functions as you currently propose, by returning to the original frame source. For XSS reasons, finding the current location shouldn't be possible, and if it was it would be considered a bug and fixed in subsequent browser patches, so it might not be best to rely on such a quirk if one existed. A way to elegantly break out without revealing location would be nice, though. This might be something you can propose to the HTML5 group.
Not that it would really be all too helpful, but the closest you can come is detecting if someone actually left the original frame source page. When you navigate a frame the history object maintains entries, and if your original history length when the page loads is greater than the history length when someone clicks "Break out of this frame...", then you know they were browsing in the frame.
I appreciate both you (hal10001) and Zach taking the time to answer. It appears I'm suck (as I suspected) because of the xss security concerns.
I suppose I could simply wrap all the content within a php based proxy, but that would clearly entering the creepy zone, not to mention the added latency and what-not.
I'll keep spinning the idea incase I do come across something sane and usable, but until then I guess I'll just use the slightly less freindly approach of promoting the original frame and wiping out their current location (and if they don't like I can revisit the iframe/toolbar situation.
Thanks again!