Microsoft Edge requesting new page on back/forward button - microsoft-edge

The latest version of the Microsoft Edge browser (41.162...) requests a new page when the back and forward buttons are clicked. I've tested multiple browsers on multiple platforms and only Edge exhibits this behavior.
Here's a test page that displays the timestamp the page was created. Click the "Next Page" link and then use the back and forward buttons. Notice that the timestamp is different each time for Edge but not other browsers.
The previous version of Edge did not request a new page each time.

I don't think StackOverflow is the best place to post this as there won't be an easy workaround for this beside circumventing most of the browser internals via your own UI & cacheing and that can be broken by the user clicking the back button that they're accustomed to. I recommend filing a bug on Edge here: http://bugs.microsoftedge.com to find out if it's by design or not and potentially get it fixed. Additionally, please make sure to state why this is impactful to your site and more importantly to your end users.
One reason I can see fetching the URL again is that the content will be fresh because not every user wants to go back to "stale" content they just want to go back to that page, for example - and doing a new navigate ensures a clean slate.

Related

surveymonkey popup not showing

I setup a wordpress blog and wanted to add a popup from surveymonkey. To simply test if it gets loaded I added the script within the footer.php before the closing body tag. Then I reloaded the page but the popup didn't appear, I tried the same with an empty html page where it did work.
Then I compared the developer console and it seems that not everything gets loaded. For some reason after the object has been loaded nothing else gets loaded. I even tried to add the script to another project (not wordpress) but it doesn't work either.
I also tried to setup a new collector and added the script tag again to my project. The popup has been loaded, but after I reloaded the page the same happens as before. It does work though when I use an embedded survey, instead of a popup survey.
Here are my results on firefox:
Any page
Empty page
What am I doing wrong here?
Wanted to add in the edit This is the correct answer but also I wanted to give context to why the default nature SurveyMonkey creates here is not good. If the end user activates the survey a single time the fact that it would not open again makes no sense and is a poor user experience.
The user would never know, if they closed the survey prematurely, that there was no reason that the activation of the survey could not be completed again.
SurveyMonkey allows for the survey to be taken again until it is completed and then the survey would explain to the user they have already completed the survey. This is a good user experience and sufficient.
***End edit
Just chiming in here, despite this being an old question. The previous answer is absolutely correct as the Survey Monkey popup will only display once and there's nothing you can do via the Survey Monkey interface to get it to show multiple times in a single browser session.
However, you can resolve this issue by adding the following JS above your Survey Monkey JS code:
<script>document.cookie = 'smcx_0_last_shown_at=;expires=Thu, 01 Jan 1970 00:00:01 GMT;';</script>
This code clears a cookie created by the Survey Monkey pop up that keeps track of when it was last displayed, so it'll display every time the page is refreshed without the need to end the current browser session.
I know this is an old question, but I am posting a reply in case it helps someone else. It appears that Survey monkey limits the number of time the pop up shows to once per browser session.
I have tested in Chrome, Firefox & Edge and I was able to reproduce this behavior very consistently.
If either the embed or the pop has shown up once, the pop up will not show up a second time until you either close and re open the entire browser, or load the page in incognito/private browsing mode. But you will still need to close and re open the private/incognito browser window/tab each time you reload the page containing the pop up.
As of yet, I have not found an option within the Survey Monkey interface to disable this behavior for the pop up survey. Note that the embed survey does not suffer from this.

Jquery Mobile Logon Loop

Knocked-out a simple jQuery Mobile site with [logon -> index -> content] pages.
If I use the back button to the logon page, I can't escape no matter what I do - forward, back, filling it in, nothing.
I'd like to remove the #logon page from the navigation, so you cannot get back to it without typing it in, or logging out - any advice?
Easiest way to keep a page from showing up in history (with jquery mobile) is show that page in a dialog. This model works particularly well in situations where the content that would be in a dialog is either tangential to the main content or some sort of interrupt (which the login process is). See an example here. DISLAIMER: this is not the right way to implement content like this in the long run, it is only meant to show the effect of using a dialog in a login process to bypass insertion into history.
Another (more manual) route would be to use the a normal jqm page and do your login by way of an ajax posting. If the response came back as successful, then use location.replace() to remove the the current (logon) page from history.
I ended up removing the ajax navigation full stop and sticking to manual, not as pretty but headaches avoided!

Alternative way of Page.IsPostBack

I am into iPhone, Android and Blackberry web programming. I am struck into an issue in which i either need to stop refresh of page (which according to blogs is not possible) or i need to just refresh the page rather than submitting.
I have used basic HTML controls not ASP.Net server controls, so Page.IsPostBack cannot be used to differentiate between page refresh and a postback.
Alternatives that i have tried:
The root of the issue is that : Having used Request.Form Collection which are read only and are only updated on a postback. So, on a page refresh the Request.Form collection is having previous values and thus submits according to previous request.
I have tried using cookies as found in this link: http://hi.baidu.com/cxyking/blog/item/508872346135283c5ab5f53c.html
It is able to detect a page refresh only after it has already loaded. While my requirement is that i need to detect page refresh before the original page has been unloaded.
I tried to use OnBeforeUnload to display some warning message. But, this only works in desktop browsers and iOS does not seem to do anything on this event.
Is there any idea on how i can do any one of following:
Completely stop page refresh.
Display warning message to user for not leaving the page (OnBeforeUnload not working on iOS)
Somehow, update Request.Form Collection (Note that it has a Set but it is readonly, so it doesnt work)

How to redirect user to the page they were just at without them noticing?

The website viewer would be at page A, click a link that sends then to page B, but I want them to return to page A without them noticing.
When they click the link it changes the layout the viewer is browsing the site with, so the redirection code shouldn't erase or undo the cookies or whatever are stored with the link click. Thanks!
Edit:
Here's what I'm doing. I have a page called setskin.php that has php code that takes header and footer codes for different layouts and applies them. I don't know how to show code without it going crazy, so there's a screenshot of it here:
http://figmint.uuuq.com/Picture%202.png
I want to change my website so that in a sidebar there will be the same setskin options (so it will be on every page). I was fiddling and managed to make it so when you click the link for the skin you want it changes the skin, but then you end up at the setskin.php page, which I don't want. I was looking for a way to make it so it sends you to the setskin.php page (since I couldn't see how to change that) and then back to where you came from.
You should use AJAX. That way you can do whatever processing is needed behind the scenes with zero impact on the user.
You can check the referer header and return to that. But if that isn't set go to a default page?
Other options include putting the previous url as a parameter, like a 'next' parameter. Then redirect to that after you're done. Quite common pattern used for login.

Is it acceptable to make external links target="_blank"?

I'm a bit confused whether or not I should make the links on my website that point externally target="_blank". Does this practice negatively affect the usability of your site (i.e. breaking the "back button trail")? Is it commonly found annoying by most users? Is it acceptable in some situations but not others?
I want to make an enjoyable user experience for all of my sites and would hate to do something that annoys my users. What is your experience/advice on the matter?
Most people will say to leave it out, all for very good reasons.
Most people will not tell you this: watch how different people browse using their computer. Sit down for an hour with an average user: a teacher, a piano player, a retired Vet, a stay-at-home mother, or a mechanic. Watch how people who are disabled browse.
You will discover that you should not:
Open new windows (it is highly confusing)
Have menus disappear immediately after leaving them (requires fine motor control)
Use excessive numbers of links on a page (also confusing)
Provide too many features and options
Use Flash animation
Be overly clever
You will discover that you should:
Be clear and concise
Be simple
Keep the user on the same page
Avoid frustrating the end user at any cost
Create an extremely responsive website
And much more.
I've read plenty of usability documentation suggesting that end users resent being forced to open a link in a new window. I tend to agree, if I want a new window I will right click and select whether I want the same window, new tab, or new window.
However, the marketing types believe that opening an external link in a new window will keep the end user on your site because they will eventually close the new window and wind up back on your site.
EDIT: Best information I've read on this subject is in Steve Krug's book "Don't Make Me Think" (website).
MHO: just link it. If I want to open the link in a new window, I can do it myself.
Leave the target attribute out and let your users decide if they want to open the link in a new window. If you want to warn the user that the link will take them away from your site, you can implement a page that makes it clear (US Government sites do this for instance).
I agree that as a user, I prefer to have the choice as to whether or not I open a link in a new window. Unfortunately, many users don't realize that they have that choice, and will lose your website when they click a link to an external site. I tend to err on the side of caution and make external links open in new windows, but it depends on your audience, really.
Here is a nice write up for not opening links in a new window/tab from Smashing Magazine. Essentially, it is better to give users control over link behavior than to decide for them.
Usability guru (?) Jakob Nielsen suggests not opening new browser windows (It's 10 years old though).
Quote:
Opening up new browser windows is like
a vacuum cleaner sales person who
starts a visit by emptying an ash tray
on the customer's carpet. Don't
pollute my screen with any more
windows, thanks (particularly since
current operating systems have
miserable window management). If I
want a new window, I will open it
myself!
Designers open new browser windows on
the theory that it keeps users on
their site. But even disregarding the
user-hostile message implied in taking
over the user's machine, the strategy
is self-defeating since it disables
the Back button which is the normal
way users return to previous sites.
Users often don't notice that a new
window has opened, especially if they
are using a small monitor where the
windows are maximized to fill up the
screen. So a user who tries to return
to the origin will be confused by a
grayed out Back button.
And, every rule has an exception: He suggests document like PDF or DOC that are opened in the browser should be opened in new windows, to avoid confusion.
It's worth mentioning that target isn't valid in XHTML anyway.
I think it depends on the situation. For a simple website with just a few links like about us, contact, services etc., I will not open new window. It is easy for the user to know which page they are at and which page they have just looked at. For a site that has a listing summary page which links to hundreds or even thousands individual listing page. I would prefer to open new window for each listing. It allows the users to compare service/price.... on each opened page. Plus the user doesn't have to click the "back" button to return to the summary page and wait for the same page to load again.
It depends, typically for links to additional content on your site, I would not use the _blank. Anytime I link to off-site content I use the _blank to keep a page open for my site. That way when the user is done on the external site they see my site again.
With modern browsers this usually opens a new tab. I expect this behavior, but usually I control click to get a new tab/window when I want to keep my place.
That being said, for a web application, I'd always leave the target attribute off so the user can decide to open a new window or not.
What people hate is opening links in a new window and not knowing that it's coming. For each external link, go ahead and use target="_blank", but add an icon that suggests you're opening a new window. Wikipedia's double square icon is a good example of this, so you can just grab that from them and capitalize on the literacy that users already have there.
What's great about a 'new window' icon is that users then have the option of opening in a new tab instead, which isn't so obtrusive. I'd also say that many of those vehemently arguing against your proposed approach are looking at it strictly from an aesthetic/usability standpoint, and not in terms of business requirements or the functionality of your own application.
If you think that you or your users stand to gain from keeping users on your site and opening external links in a new window, you get to make the final call on that. Just be respectful about it.
You need to consider what users are doing in your window, when deciding how links should behave. If I could potentially lose a lot of work by navigating to another page, then I might want links to open in new windows, or give me an option to cancel.
For example, if I'm composing a message in Gmail, most of the links show a confirmation dialog, so I don't accidentally lose my work. And the links on top, which go to other applications like Calendar, open in new windows. I think this is a good example to follow.

Resources