Environment:
IE9 with Group Policy applied and an automatic proxy script, which defines a set of internal (using DIRECT) and external sites are redirected to a proxy.
Desired behaviour:
Starting from an internal web site page, clicking on an external link makes IE navigate to the external page directly.
Problem:
If IE is not run as administrator, IE redirects first to about:blank for about a half a second, and then to the external page.
This is a problem when we try to prevent navigation to certain URLs by cancelling the BeforeNavigate2 event in a Browser Helper Object.
The problem is that when we try to prevent the navigation, the browser shows the about:blank page instead of staying on the original page.
Related
I created a web page using GitHub Pages. I added the custom domain by following the Settings>Pages path. The page redirect was successfully performed by creating the CNAME file.
I wanted to cancel the page redirect after a while. Therefore I removed the CNAME file and followed all the steps mentioned in the documents. But I was not able to cancel the page redirect. How can I fix this problem?
Since the website redirect is saved in the browser's cache, the redirect will continue even if the redirect is cancelled via the Settings>Pages tab on GitHub; this will automatically cause the CNAME file to be deleted. The way to solve this problem:
Remove the previous redirect by going to Settings>Pages on GitHub.
Rebuild the page via the Actions tab on GitHub.
Click the F12 while the browser is open.
Long click on the refresh button on the browser.
Select the Empty Cache and Hard Reload option.
When you try to enter the website again, you will see that the redirect has been cancelled.
I'm not sure how to make this question reproducible because it requires having a Vimeo paid (or on a free trial) account.
Vimeo recently changed their UI for creators and made it harder to access one of the pages I use every day.
From https://vimeo.com/manage/videos there is a table with links to individual videos. The URL for each link is something like https://vimeo.com/55555555555555/settings.
If you click, it sends you to Page A: https://vimeo.com/manage/videos/55555555555555.
Then, there's a button that sends you to the page I actually need (Page B): https://vimeo.com/manage/55555555555555/general.
The problem is that when I enter the URL for Page B directly in my browser, it redirects me back to Page A.
Strangely, the back/forward buttons navigate between pages A and B, and the refresh button also stays in Page B. But if I copy Page B's URL, open a new tab and paste it, it sends me back to Page A.
To figure out what's going on, I looked in the network tab of the Chrome Developer tools and found that the first request from Page A to page B looks like this:
But then, if I paste that URL in a different tab, I get a 302:
I've diffed both requests:
Is there a way to prevent the 302 behavior?
I don't have a vimeo account and thus can not test it. Ultimately, the server could use any parts of the diff, but I'd expect it to use the referrer.
Does the page always direct you back if you completely disable setting the referrer in Chrome? If so, using a plugin to forge your referrer could solve the issue.
Unlike 301 redirects which are permanent, 302 are not. The web server displaying 302 errors should redirect the browser and take you to the new location immediately. It should be noted that HTTP 302 status code is due to the web server and not the web browser. There is no control at your end.
I am trying to debug a webpage with chrome developer tools and the page redirects to a pdf file after it loads. I checked JavaScript files and there is not any place that we redirect the page. I cannot find any related message in developer tool console or network tab.
I activated event Listener Breakpoints -> beforeunload but it stops at an external js file (Placeholders.js) which is not related to redirecting.
Also, preserving Logs in network tab does not help me on finding root cause of redirect.
I am wondering how can I find the source of this redirect?
UPDATE: There is not any "refresh" meta tag in the html code.
There are a couple of things you can do. You can use the Event Listener Breakpoint -> Load - unload and then when it breaks in the 3rd party library, right click and select Blackbox Script. The next time you play through the code, it should only break in your own code (assuming there are no other 3rd party libraries to blackbox).
Another option is to go to the Network tab and check the Preserve Log checkbox. This will persist all requests between page loads/navigation, so that you will be able to find the network request that returned the PDF response.
I have an application running in an iFrame that is embedded in a SharePoint site. The problem with this is navigation within the application does not result in a change in the SharePoint site URL. Therefore, if you were to refresh the overall page, you would be sent back to the default page of the application, not stay on the same page of the application. The reason this is an issue is sharing for social media. I have added a Facebook Share button to the application, but when it pulls the URL of the application which does not match or reference the URL of the overall site, so it just shares the application (which is not visually appealing and does not allow you to access the rest of the site).
Any body have any suggestions or know a place I can go for help? Thanks!
If I understand properly, the Facebook stuff is INSIDE the iframe?
If so, you can:
* Remove the iframe and integrate the application better with SharePoint, or
* Change the application so that it detects that it's running "alone" (with javascript etc), and if so redirect to the "big" application.
IF the Facebook stuff is in SharePoint, OUTSIDE of the iframe, you can write some javascript to update the URL in some way that matches the URL of the application. This requires that the SharePoint parent application and the iframe application run in the same domain - if they are not, this is not an option.
Note that changing the "parent" URL with JS will reload the page, UNLESS you only change the URL after the "#" part (so you can do something like:
"http://sharepoint/iframe.aspx?aa=11&bb=22#iframeUrl=http://uglyapplication/"
You'll also probably want to write JS to update your iframe accordingly if the user press "back"/"forward" etc in the browser, because changing the URL like above will still add a "step" to the browser history.
I'm getting a strange issue only Chrome + Firefox. It doesn't repro on IOS or IE9.
Here's the repro:
Load Home page http://example.com
Login (via a rel="external" hyperlink). In my case I use Facebook's Oauth Server Side flow - so this URL is a facebook.com.
Facebook accepts the user's credentials and then redirects to http://example.com/user/callback. Here various facebook data is processed (it is provided in the query string).
The server side code at http://example.com/user/callback then redirects the user to http://example.com. The mechanism used for the redirect is a RedirectToAction from ASP.NET MVC3. This returns a 302.
Expected Result:
User would see a URL in their browser = http://example.com and the content all nicely shown. This works on IE and Safari.
Action Result (on Chrome Only)
User gets a URL in their browser = http://example.com/#base_domain=example.com
The actual page is blank (no visible content)
However a view source reveals that the content is present.
Action Result (on Firefox Only)
User gets a URL in their browser = http://example.com/#_=_
The actual page is blank (no visible content)
However a view source reveals that the content is present.
Additional Info
If I enter the URL http://example.com/#base_domain=example.com into IE I get the same 'hidden' content (i.e. blank page with HTML source still present).
I should also note I use the RedirectToAction/302 redirect technique in other parts of the application with no issues whatsoever.
The issue also repros with AJAX navigation turned off.
EDIT: This also works on Safari (OSX + Windows) with no issues. It's only apparently broken on Chrome + Firefox on both Windows and PC.
IOS/Safari: OK
Win/Safari: OK
Win/IE: OK
Windows Phone Emulator: OK
Win/Firefox: borked
Win/Chrome: borked
OSX/Safari: OK
OSX/Firefox: borked
OSX/Chrome: borked
Not sure about Android.
The best solution appears to be setting the Push State and Hash Listening to false - so chrome/ff completely ignore them. I already had AJAX navigation disabled (there some interesting behaviours with it I hadn't completely accounted for yet with my server side code).
$.mobile.pushStateEnabled = false;
$.mobile.hashListeningEnabled = false;
I'll probably wait for 1.1 and stabilise the rest of my code before trying to get AJAX navigation working.