Closed Bug 606286 Opened 14 years ago Closed 12 years ago

Back button should work for websites that quickly redirect

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla16

People

(Reporter: stechz, Assigned: torisugari)

References

(Depends on 1 open bug, Blocks 3 open bugs)

Details

(Keywords: qawanted)

Attachments

(1 file, 1 obsolete file)

Proposal v1.1
4.80 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review 
Sometimes it is impossible to go back if a web page quickly redirects to something else. We could add some heuristics to see if location is changed by script within a second or so after the page loaded, and automatically take that out of session history perhaps.

This is more important now that dropdown back button is less discoverable.

Maybe this is a docshell feature? I put it in Firefox frontend for now.
OS: Windows 2000 → All
We have code that attempts to handle these cases already, but perhaps it is broken in some circumstances. A testcase or STR that demonstrate the issue would be ideal...
Component: General → Document Navigation
Product: Firefox → Core
QA Contact: general → docshell
Summary: Back button should work for websites that quickly redirect → Back button should work for websites that quickly redirect (quick redirects are being saved in session history)
(the code in question is in nsDocShell, search for "LOAD_NORMAL_REPLACE")
Carrying over Alex Faaborg's blocking request from bug 615306. If this is a regression I would think this should definitely be a blocker in addition to reasons already provided.
blocking2.0: --- → ?
status2.0: --- → ?
Whiteboard: DUPEME
Clearing nomination for lack of a testcase. In every case I know of, the back menu will get you there even if a single click on the back button doesn't. Please renominate if a testcase shows a recent regression.
blocking2.0: ? → ---
status2.0: ? → ---
It's an important usability question. Indeed, the back menu can always be used. However, I assert that a single click on the back button should always do the thing which is semantically most correct to the user. In this instance, that is most assuredly not to leave you where you were when you clicked the back button, which apparently occurs because the next thing back on the stack is a quick redirect.  I am but a user, incapable of helping with development, but I remain, after about 18 months, as unsatisfied with this situation as ever. IE8 and its predecessors have never exhibited this syndrome. Test cases abound at www.mercurynews.com. Click on any story and then try to return to the main page with a single click of the back button.
> Test cases abound at www.mercurynews.com. Click on any story and then try to
> return to the main page with a single click of the back button.

Works fine for me, both in Firefox 3.6 and on trunk.  Specifically, I did these steps:

1)  Load http://www.mercurynews.com/
2)  Click the "Courtroom drama: Woman confronts man who shot her, killed
    fiance" headline (the one near the top left).

There are no entries in session history between the one for the main page and the one for the story, and clicking "back" once goes back.

So I'd like to second Gavin's request from comment 2: detailed step-by-step instructions on actually reproducing the problem.
When I filed my duplicate bug I was unaware that we had fixed this.  So unless someone can find a case where it doesn't work, I think we're now fine with removing the drop down next to the back/forward controls.
Neither JS nor <meta http-equiv="refresh"> redirects are currently handled, AFAIK.
Alex, I can trivially create a site where the redirect is not "quick" enough for our code to consider it quick, and where you or I could hit the back button twice quickly enough to go back, but where my grandmother couldn't do so.  So I don't think we want to be removing the dropdown.... but maybe it's just me: I actually use this (via context-click, of course, since there's no other UI for it on Mac).
(In reply to comment #11)
> Alex, I can trivially create a site where the redirect is not "quick" enough
> for our code to consider it quick, and where you or I could hit the back button
> twice quickly enough to go back, but where my grandmother couldn't do so.  So I
> don't think we want to be removing the dropdown.... but maybe it's just me: I
> actually use this (via context-click, of course, since there's no other UI for
> it on Mac).

Just to clarify, the drop down is still there, but not as a pulldown icon next to the buttons, but on the buttons themselves (right click or click-and-hold).
(In reply to comment #10)
> Neither JS nor <meta http-equiv="refresh"> redirects are currently handled,
> AFAIK.

I'm not sure what you mean by "handled", but both cases in the following testcase behave as I would expect them to, after clicking the link and then clicking "back":
http://gavinsharp.com/bug/606286/
(In reply to comment #9)
> When I filed my duplicate bug I was unaware that we had fixed this.

We haven't "fixed" this any time recently, fwiw - the code that handles this has been around since approximately forever :)
e.g.:

data:text/html,<script>setTimeout(function () { document.location = "data:text/plain,go back!" }, 0)</script><body onunload="">
If you go to http://listen.grooveshark.com/, you are redirected to http://listen.grooveshark.com/#/ and can not go back in history without accessing the back button dropdown.
Thanks for comment 15 and comment 16.  So it sounds like the key is to make the location change after onload has fired, but "soon after that".  What defines "soon"?  200ms is probably "soon".  What about 2s?  Like I said above, I can easily click the back button twice in 2s; my grandmother can't.  And I'd be pretty annoyed, personally, if sites that only show for about 5s got nixed from session history (because I often want to do something like "view source" on that intermediate site).  But maybe that's not a common user complaint.  ;)
Why would this apply to button presses at all? I would expect this to only apply when location is changed by script.
I don't understand comment 18.  What are you actually asking?
(In reply to comment #19)
> I don't understand comment 18.  What are you actually asking?

I mean the origin of the location change. If the user types in a new URL or clicks the back button, the original URL should stay in history. If the location change spawns from a setTimeout or from a load event, we should not commit the original URL to session history.
OK, sure.  Where did anyone apply anything different?
I misunderstood comment 17. I didn't see why the speed of clicking the back button was relevant, but it's relevant in that small constants (like 2 seconds) may still overwhelm users.

Besides view source, is there anything bad about having a relatively large constant for this? 10 seconds? Can anyone think of any cases where a user would want to hit back to get to a redirecting page?
Cases where the page says _why_ it's redirecting and the user would like to read that, but doesn't read fast enough at the (probably tiny) font size used to get through the whole thing before the redirect?  Again, more of a problem for younger and older folks than me and you, but still a problem.
(In reply to comment #23)
> Cases where the page says _why_ it's redirecting and the user would like to
> read that, but doesn't read fast enough at the (probably tiny) font size used
> to get through the whole thing before the redirect?  Again, more of a problem
> for younger and older folks than me and you, but still a problem.

I'd argue that this isn't how redirects are used on the web anymore. :)

Could we increasing the timeout to at least 10 seconds, or remove it altogether?
There is no timeout right now.  A new load that starts before onload has fired is treated as a replace load; anything else is not.  We'd need to implement such a timeout, and do so without breaking pages.  Note that this includes pages that do programmatic history navigation and may do so while assuming things about what is and isn't in the history.

Also, the HTML5 spec is going to specify behavior here; I suggest reading over what it says now, and bringing things up in the whatwg if what it says doesn't match what we want to do.  We don't want our hands to end up getting tied by what the spec says.
At some point I was asked for a better example at the San Jose Mercury News. www.mercurynews.com; Unfortunately, I have not determined an algorithm for when this redirect shows up. You just have to try a bunch of links until it happens. They let you have one or two stories for free. After that you need an account. The redirect is through a page that checks cookies and either prompts for account information or lets you in. Since I have an account with this paper, and it's probably paid, it's not clear whether you'll be able to reproduce the problem without spending some $$.

Don't know their algorithm, but today I encountered the problem by clicking on a first story, clicking Back, clicking on a second story, and then examining the session history. The second time the redirect was there and I either had to use the back menu or click twice very quickly.

It's a pity that redirect URLs don't have an identifiable tag that makes it clear what they are; then the need for timeouts and the like could be avoided.  FWIW, I have no objection to the redirecting URL appearing briefly when first invoked, but I believe it should not be left on the stack where it causes this endless unwanted looping.  I'll shut up now.
Whiteboard: DUPEME
Whiteboard: [target-betaN]
 
> Just to clarify, the drop down is still there, but not as a pulldown icon next
> to the buttons, but on the buttons themselves (right click or click-and-hold).

It is indeed,but is pretty much "hidden" for the majority of users,no tooltip as of now points to this feature.
1.  Please don't even *THINK* about removing the 'recent pages' navigation history.  It is valuable far beyond getting trapped by a redirect:

 A. Hopping along a path of links often gets you to a point where you just want to get back to some specific page without having to 'back' (or 'forward') button repeatedly.   
 B. It's also VERY handy for jumping between two pages you need to reference when there's intervening pages you don't care about.  

Forcing use of only back/forward also means you have to wait to see each page if you're not sure how many pages you're trying to skip over, and is especially annoying if the list is long.

2. To echo others: The 'press and hold' or 'right click' at least keeps the function, but it is NOT obvious, and even inconsistent since other buttons don't have similar expanded functionality.  

Having the pulldown marker is clearly preferable to 'hidden' functions.

If having the pulldown marker is so onerous, make it a customize toolbar or about:config option.  

As a MINIMUM, the back/forward button tooltips should read something like:

   Go back/forward one page
   Hold for page list
Comment 28 and related are completely off topic to this bug. Nobody is going to remove the history in the context menu for the back/forward buttons and debating the merits of the dropdown arrow are not this bug. (file a new bug if you want to request better discoverability, which is all well and good, but not this bug)
Could this be resolved by adding a user confirmation for script redirects?  To minimize annoyance it could be optional, and by default only apply to pages in session history.
another missed target?
(In reply to Shad Sterling from comment #30)
> Could this be resolved by adding a user confirmation for script redirects? 
> To minimize annoyance it could be optional, and by default only apply to
> pages in session history.

I think that's basically a very good idea. However, I guess we will have to rewrite many mochitest scripts, because most scripts use location.href = "..." in navigating test pages, including session-history tests. Well, surely I can't push back button effectively during those tests, like comment #15.
(In reply to Benjamin Stover (:stechz) from comment #20)

> If the
> location change spawns from a setTimeout or from a load event, we should not
> commit the original URL to session history.

And why so ?

(In reply to Benjamin Stover (:stechz) from comment #22)

> Can anyone think of any cases where a user
> would want to hit back to get to a redirecting page?

I think these addresses that quickly redirect have to be kept in Firefox' History, and in the Back button's navigation history.

Primo, for consistency's sake. These histories record the pages where I go, so even if I go somewhere only during 0.10 second, I went there, this has to be recorded in the histories, I may want to find later this address where I went, I may want to view its source, I may want to go there again…

Secundo, to allow the user to fight back. Nowadays, redirections are not always well intended nor even honest. Usability and accessibility, and the W3C's guidelines in these matters, forbid that a change happen after some duration without user action. But not everyone obeys that. Sometimes — and not only on porn sites —, the Web address swiftly diverts you to some kind of ad stuff instead of letting you view its real story. So the Back button must be enabled, to help you understand what happened. And you still want to view the story. So you go back to the original Web address. Often, this is enough, because the ad stuff or redirection doesn't show again. Sometimes, it kicks in again, and, after you have tried several times, you get the real story. Sometimes, you tweak the original Web address to go to a simpler address and you get your real story. Similar use cases occur with “not found” pages. You land on a page telling that your requested story is not found, sometimes telling you why ; and you get swiftly redirected to the site's home page. So the Back button has to be enabled, to help you understand what happened. And the originally requested page has to be in the histories, because you were interested in that story, not in the site's home page. So you can go back to this address, view the address of the story, with its title sometimes, and you use that info to proceed as follows. You know what you missed, and you forget about it for now. Or you are really interested in that stuff and you look for it…
(In reply to Nicolas Barbulesco from comment #33)
I would think leaving all pages in the history is fine. The issue here is just the back button. If on some sites it doesn't work due to a quick redirect on the previous page, then there's no reason we should have to have the back button using the full history. Sure, if the site is a particular mess you might need more and it would still be in the history, but we just want the back button to actually be able to always go back.
I think the problem you have is not in fact in the Back button, but in the (too) quick redirect. About this problem, see my comment here :
https://bugzilla.mozilla.org/show_bug.cgi?id=615306#c3
Let me repeat what I have said before.

Italian ordinals aside, there appear to be uses for redirect that are for the pure benefit of the web service and not germane to the user. Case in point is the San Jose Mercury News, which inserts an authentication check into attempts to leave its home page. If the authentication succeeds from stored credentials without prompting the user, the user is immediately redirected to the originally selected link. The Back button returns to the redirecting page, repeating the process, which means you remain trapped on the selected article. This is WRONG. 99.995% of users are not interested in what's going on under the covers. They just want the right thing to happen. Responders frequently suggest some sort of timing issues as the approach to resolving this. I would suggest that the stack keep track of which pages were left by explicit user action and which not. BACK would return to the most recent page left by user action. Experts could use the stack view to achieve a less likely aim.

As a user, not an implementer (of Firefox), I can only plead. But plead I do.
Is this somewhat related to bug 687300 ?  And is there any a11y guideline about this issue, e.g. UAAG1.0-3.5 for bug 83265 ?

http://www.w3.org/TR/2002/REC-UAAG10-20021217/guidelines#tech-configure-content-retrieval
Indeed.

From the W3C, I read the techniques for the guideline “3.5 Toggle automatic content retrieval (P1)” : www.w3.org/TR/UAAG10-TECHS/guidelines.html#tech-configure-content-retrieval :

“Allow configuration so that the user agent only retrieves content on explicit user request.”

“Provide a configuration so that when the user navigates "back" through the user agent history to a page with a client-side redirect, the user agent does not re-execute the client-side redirect.”
A further example of this problem is described in a pdf.js issue on github: https://github.com/mozilla/pdf.js/issues/809

Specifically, some google searches apparently insert a JS redirect in between the search page and certain PDF results. This interacts poorly with the pdf.js addon if you try to go back to the search result page from the PDF viewer.
(In reply to Dan Swinehart from comment #36)
> Responders frequently suggest some sort of timing issues as the approach to
> resolving this. I would suggest that the stack keep track of which pages
> were left by explicit user action and which not.
It sounds like this could be implemented by cannibalizing the logic from a pop-up blocker.

Alternately, I wouldn't expect it to be too hard to catch an onload-settimeout and flag the page as a redirect, although there would definitely

> BACK would return to the
> most recent page left by user action. Experts could use the stack view to
> achieve a less likely aim.
I'd also find BACK returning to the most recent page (as it does now) acceptable if pages loaded using the BACK button were unable to redirect without the user being prompted.

Then our user story is: The user presses back. The previous page attempts to redirect. The browser asks the user whether to redirect. The user declines. The user presses back again. The user is now at the page the user wanted to be on.

For users who actually want to see the redirect page, they would no longer have to attempt to manually interrupt the redirect process.
It seems I didn't finish my thoughts in the second paragraph of my previous reply.

Alternately, I wouldn't expect it to be too hard to catch an onload-settimeout and flag the page as a redirect, although there would definitely be pages that this approach would miss.
There are 2 methods to guard the back button.
* [1.] Replace the session history entry.
* [2.] Block loading per user's preference.

Gecko's <meta http-equiv refresh> does both [1. replace] and [2. block].
Gecko's location.href/location.assign() does [1. replace] on loading.

Webkit does [1. replace] on loading, as much as possible, including location.host, window.open() and form.submit() besides location.href/location.assign().

HTML5/WHATWG refers to only <meta http-equiv refresh> and location.href and the solution is [1. replace].

The remaining, in my opinion, issues in Gecko are:
i.
Gecko should drop the [1. replace] support for |location.assign()|.

Please note that the proposed behavior is clearly *against* the purpose of this bug, but that is what the spec requires. And that makes much sense, at least to me, for the difference between "location.assign()" and "location.replace()" is simply how to handle the session history. Probably we should not change the behavior of the sesion history on |location.assign()| under any condition, unlike |location.href|.

ii.
How to handle the cases other than the spec says.
i.e. window.open(), location.host etc., form.submit(), anchor.click(), NPN_GetURL() and so on.

I'm afraid the spec won't mention [2. block] for the time being. And I guess, as far as [2. block] is concerned, the compatibility among browsers is less important than that of [1. replace]. In other words, by [2. block], Gecko can cover the things left out of [1. replace], while it is true to the current session history's spec (and that in the future if we want to modify the spec).
Blocks: 754029
Attached patch Proposal v1 (obsolete) — — Splinter Review 
When
1. a new user pref "accessibility.blockjsredirection" is set true.
2. the user is browsing back/forward history.
,
JavaScript redirection, such as window.open(...), location.href, location.host, location.path, ... , location.assign(), form.submit(), anchor.click() will be blocked.
Attachment #627465 - Flags: review?(bzbarsky)
Comment on attachment 627465 [details] [diff] [review]
Proposal v1

So this behavior is preffed off by default, right?

Put the '{' at the beginning of the function on a separate line, and r=me.
Attachment #627465 - Flags: review?(bzbarsky) → review+
> So this behavior is preffed off by default, right?

Right, as long as "accessibility.blockautorefresh" is also off by default.

Probably I (or someone else) should merge "accessibility.blockautorefresh" and "accessibility.blockjsredirection" into a single pref key, so as not to confuse users/UI-devs. However, before doing that, we need to modify nsIRefreshURI::ForceRefreshURI(...) and nsIWebProgressListener2::onRefreshAttempted(...), because the current nsIRefreshURI::ForceRefreshURI(...) don't send HTTP referrer. That's not acceptable for anchor.click(), location.href and so on.

The modification should not be very complicated, but the name of the API "on*Refresh*Attempted" etc. would be misunderstanding since the term "refresh" now purely refers to HTTP "refresh:" header or <meta http-equiv="refresh">...
Attached patch Proposal v1.1 — — Splinter Review 
Added a line break, addressing:

(In reply to Boris Zbarsky (:bz) from comment #44)
> Put the '{' at the beginning of the function on a separate line,
Attachment #627465 - Attachment is obsolete: true
Attachment #629175 - Flags: review?(bzbarsky)
Comment on attachment 629175 [details] [diff] [review]
Proposal v1.1

I said r=me, right?  ;)  I trust you to add a newline correctly and all... ;)
Attachment #629175 - Flags: review?(bzbarsky) → review+
(In reply to Boris Zbarsky (:bz) from comment #47)
> I trust you to add a newline correctly and all... ;)
Thank you, but it's not clear to the person who is going to commit the patch, is it? And of course I often add newlines at wrong places.

In my opinion, bugzilla should allow a new patch to take over flags in an obsolete patch, as well as setting "checkin-needed" flag per a file, "already-checked-in" flag per a file. It's wonderful if a bot posts a flagged patch to try-server automatically.
Keywords: checkin-needed
Summary: Back button should work for websites that quickly redirect (quick redirects are being saved in session history) → Back button should work for websites that quickly redirect
Whiteboard: [target-betaN] → [target-betaN][Needs UI]
Assignee: nobody → torisugari
>> I trust you to add a newline correctly and all... ;)
> but it's not clear to the person who is going to commit the patch, is it? 

What I usually do when committing checkin-needed patches from people I don't know well, when they've addressed review comments and posted a new, unreviewed patch, is pull up the interdiff between the r+'ed and new patches, to make sure it looks sane.  I imagine most people who look at checkin-needed bugs do the same.

> In my opinion, bugzilla should allow a new patch to take over flags in an obsolete patch, as well as 
> setting "checkin-needed" flag per a file, "already-checked-in" flag per a file.

You can set checkin? on your patch, and when someone commits it, they can mark it with checkin+.  I'd still set checkin-needed in the bug's whiteboard, though.
FWIW, I only look for checkin-needed on the whiteboard. To me, checkin?/+ is mainly for bugs with multiple patches where only a subset are landing. That said, attaching checkin-needed patches with commit messages is always appreciated ;-).

https://hg.mozilla.org/integration/mozilla-inbound/rev/d168da99e947

Also, sorry for the delay...
Flags: in-testsuite-
Keywords: checkin-needed
Whiteboard: [target-betaN][Needs UI]
Target Milestone: --- → mozilla16
https://hg.mozilla.org/mozilla-central/rev/d168da99e947
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Blocks: backtraps
Depends on: 774129
Has anyone else noticed this bug has come back? I am still experiencing it with 

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0 ID:20120724191344


Thank you.
(In reply to Worcester12345 from comment #52)
Based on the target milestone set up top, this will be fixed for 16.0 not 15.0.
Reproduced with Nightly 20121023030553 Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/19.0
Firefox/19.0.
(In reply to Aleksej [:Aleksej] from comment #54)
> Reproduced with Nightly 20121023030553

www.google.com → Docs (http://docs.google.com redirects to accounts.google.com).

There is also bug 788497.
(In reply to Aleksej [:Aleksej] from comment #54)
> Reproduced with Nightly 20121023030553 Mozilla/5.0 (X11; Linux x86_64;

Just to clarify... (since this bug is a little too long to read all)

If you push "back" button in your browser *slowly* as if a 150 - year - old - person did, and you can come back to this page after some web browsing, this bug is fixed, as far as docShell is concerned.

About UIs, see bug 774129 and bug 803590.

If you have no idea such a malicious web site, see mine:
http://torisugari.hostei.com/development/test/nslocation2.html

Maybe you are talking about bug 220118 or bug 687300. They haven't been fixed yet. Bug 685496 would be useful when you try to find out dups.


Then,  <http://docs.google.com> calls

> window.location.assign(url);

This is apparently a regression from bug 754029. I'm fully ready to explain why such a script is evil, but if there are too many websites like <docs.google.com>, maybe we end up backingout bug 754029. Anyway, please enable "accessibility.blockjsredirection". This bug is off-by-default enhancement.
(In reply to O. Atsushi (Torisugari) from comment #56)
> (In reply to Aleksej [:Aleksej] from comment #54)
> > Reproduced with Nightly 20121023030553 Mozilla/5.0 (X11; Linux x86_64;
> 
> Just to clarify... (since this bug is a little too long to read all)

Thanks.

> If you push "back" button in your browser *slowly* as if a 150 - year - old
> - person did, and you can come back to this page after some web browsing,
> this bug is fixed, as far as docShell is concerned.

Are you talking about the history list appearing when holding the button?

> Anyway, please
> enable "accessibility.blockjsredirection". This bug is off-by-default enhancement.

That fixes the problem with docs.google.com: the redirect does not happen, so I can press the Back button again to get to the page from which I originally went to docs.google.com.
(In reply to Brad Lassey [:blassey] from bug 788497 comment #0)

> I ran into the situation where a link from facebook went through several
> redirecters, so clicking back just resulted in seeing the content reloaded.
> So I hit back several times quickly to try to get through the redirecters
> and back to my facebook app, but I guess I hit back one too many times and
> wound up on the home screen.
> 
> This situation is ridiculous. When a user hits back they want to see the
> previous thing they saw.

Not necessarily. Sometimes, a redirecting page redirects too quickly, or gives something wrong, like an error page. In some cases, I just want to go back to the redirecting page. For instance, to retry, or to tweak the address, or just to see the address in order to know what I missed. For instance, there are wicked redirect pages who are supposed to redirect me to the target content I want but who randomly redirect to some other “partner” page. When that happens, I just go back to the redirecting page, and, this time, or the next one…, the page redirects me to the real target content. And I have another trick, which can work except when the the wicked redirecting page is so wicked that she hides the target address in coded characters. When I am back at the redirecting page, I can modify the address in the address bar in this way : I see “http://www.wickedredirectingsite.com/bla/bla/bla?target=http://www.target.com/content”, and I change it in order to go to “http://www.target.com/content”. If you need time to do that, you can quickly press “Esc” or the “Stop” button. I don't need to hurry nor to press any of these, because I have ticked in Firefox' prefs “Warn me before redirecting me”. This ill-named pref asks me before redirecting me, and redirects me only if I say “OK”. This pref does not do her job in all cases, but this is another story, which is signalled in several Bugzilla requests. If I remember correctly, the fact that this pref has to correct her text to “Ask me before redirecting me” is signalled in Bugzilla too. By the way, this pref is not at the right place in “Accessibility”, I would rather put it in “Content”.
Let's get back to our sheep. With this pref ticked, you don't need to hurry. You can click “Back” once, see the question, and click “Back” again. And so on if you stumble upon several consecutive redirecting pages. You go back to the page you want. Well, except in the cases where this pref fails to do her job.
Having the “Back” button skip redirects would prevent me from going back in some cases. It would make some pages disappear from the  tabnavigation history, and this would be *bad*. I was at these pages, even for a short time, so they have to be present in the tab navigation history. The skipping behaviour you ask could lead to losing a page, I could lose the track of the page I was supposed to go, this would be data loss and would annoy me. This would be *bad*. The wicked redirect pages I have told about are encountered typically in porn sites, but in other sites too.
And, if the “Back” button does not skip redirects, you have an easy way of going back as far as you want. Even without the pref “Warn me before redirecting me”. You can click on the little downward arrow of the “Back” button, and in the local menu you can choose the page which is before the redirect.
How is this fixed? Visit www.zdnet.com/article/microsoft-we-have-more-than-1-5-million-windows-10-insiders/#ftag=RSSbaffb68 and go back with a single click on the history-back button. Does not work.
(In reply to u526790 from comment #59)
> How is this fixed? Visit
> www.zdnet.com/article/microsoft-we-have-more-than-1-5-million-windows-10-
> insiders/#ftag=RSSbaffb68 and go back with a single click on the
> history-back button. Does not work.

"WFM".
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: