The problem is that these days a page can attach a listener to an event that indicates closing/leaving a page and they inject cookies right at that point so you can't see them with a normal cookie inspection (which requires a page to be open/current).
The way to verify (or even notice) this is to open the same page in incognito/private and see different behavior (usually the absence of "pay me pay me pay me" intrusions).
The real question is - how to find them? And then eradicate. Are there any utilities, extensions, plugins etc? Say something similar to password inspection/search in Settings.
Related
I am developing a chrome extension. When I install it one of its icon is displayed in address bar. I want that icon should not be displayed after installation.
Starting with Chrome 49 (see the announcement and detailed description) all extension icons are displayed in the browser toolbar:
[...] each extension the user has installed has a persistent UI surface. By default, this will be in the toolbar to the right of the omnibox (where browser actions are now), and the user can choose to hide ("overflow") these actions in the Chrome menu.
The reason for this is to protect our users. We've heard too frequently that many users are unaware of the extensions they have installed, whether this is due to sideloading, installation by phishing, or simply the user forgetting how many and which are installed. Unfortunately, extensions consume computing resources, and may have significant security, privacy, and performance impacts. Because of this, we've decided we need to increase user visibility.
What this means for your extension:
If the extension has a browser action: Nothing! (Apart from the slightly different hide/overflow functionality.)
If the extension has a page action: The extension will be given a persistent icon in the toolbar. On pages where the extension's page action wouldn't normally be visible, the action will be greyed out, indicating that it doesn't want to act. On pages it does want to act, it will be fully-colored.
If the extension has no action: Similar to page actions, the extension will be given a persistent icon in the toolbar. It will be shown with the greyed-out look all the time.
Displaying the action persistently, even in the cases of a previously hidden page action or an extension with no action, is necessary because the presence of an action doesn’t always correlate with the extension acting. We also can’t show the action conditionally on, e.g., a per-tab basis, because there are many actions that are not correlated with any tab. In order to ensure users are aware of the extensions they have installed that could be affecting their browser, we need to ensure each extension is visible.
We've done our best to limit the functionality this breaks, and hope you understand the trade-off between developer inconvenience and user benefit. Thank you for understanding as we keep our users safe!
An end user of your extension may manually hide the icon either by adjusting the overall toolbar width (click the space between addressbar and toolbar and drag) or by rightclicking an icon and selecting Hide or Show:
I am developing a web site where users can change settings which they have to confirm before taking effect.
The confirmation is done by a link I send them via E-Mail. In the HTML of the website I use this little snippet:
<script type="text/javascript">window.name="mysite";</script>
And in the HTML emails I use
Click me
But Chrome is always opening new tabs instead of opening them all in one.
Is this even possible or is it forbidden for some reasons?
Webmail platforms such as Gmail tend to modify some of the HTML code of an email due to security reasons.
They obviously remove any javascript code the email could have. But they also change (or add if none) the target property of every anchor element and set them to target="_blank" in order to avoid the user to be taken out of Gmail (in this case).
Unfortunately every webmail platform has their own behavior, therefore, what you want to do is not gonna work on every webmail platform.
If what you want to do is prevent the user from having multiple tabs of the same page opened, (*please refer to Update 1) it comes to mind you could use web sockets to close the previous tab once the user enters in the URL sent by email. Have a look at socket.io for example.
Update 1
There's no way to do this using WebSockets. There's no possible way to close a window that wasn't opened using javascript, and it can only be closed by it's parents.
That is a very interesting idea. I like it. Alas, it appears that, in modern browsers, you can no longer close a window you didn't open through javascript. So if you aren't allowed to run javascript in the email, the best you can do is to redirect the original page to a "thank you" page and leave it hanging around in the browser's tab (but no longer waiting on conformation). Like this:
PleaseConfirm.html:
window.name="need_redirected";
Confirm.html:
var w = window.open("", "need_redirected");
if (w)
w.location="ThankYou.html";
Of course, for old IE, I'd still try to close the old window in ThankYou.html:
window.top.close();
You can still try to set the target, of course, just in case it works, and you can always try putting an onclick attribute on your tag for the same reason:
click here
But that seems to be the best you can do. Bummer.
Neither of the other two answers work, but this one probably will:
In the initial tab, listen for an onstorage event, with a certain key being created, e.g. "userHasConfirmedEmail". When the event occurs, window.top.close().
In the new tab, create that key.
Credit goes to Tomas and his answer.
I am currently analysing my page connections and I want to block some tracking scripts and other external URL calls in my network monitor inside Chrome's developer tools.
I quickly want to check how the page behaves without some libraries.
Chrome itself does not provide any functions like this and the famous blocking extensions only block URLs which the user enters manually into the navigation bar.
As pointed out by #calavera.info, #iman.Bahrampour, and #Asim K T this feature is now available in Chrome 59. You can select a URL or domain to block in the Network panel. See this release note and these Screenshots where the StackOverflow logo has been blocked from this page. #iman.Bahrampour also shares two extensions below that will also do this ("HTTP Request Blocker" and "Request Blocker").
As abd3721 mentioned this is available directly within chrome DevTools (You don't need to be on canary anymore), however it is still behind a flag and in the hidden experimental features menu. As of the time of this comment, Chrome stable is on version 53.
To enable it, open this link and click the enable link under the appropriate flag:
chrome://flags/#enable-devtools-experiments
Then in DevTools open up the settings panel(F1) and click on the experiments tab.
This lists all currently available DevTools experiments but it is still in yet another hidden set of features.
Press Shift 6 times while in the experiments tab to show even more hidden features, one of them will be Request Blocking.
NOTE: These features are considered experimental and may be buggy or incomplete. Use with caution.
For blocking requests in google chrome you have 3 options:
1. Google Chrome with pattern matching:
In network tab, right click on request and then select block request URL
There is a plus sign that adds patterns for blocking requests
For example I have 7 request URLs:
http://www.test.com?userid=5
http://www.test.com?username=username
http://www.test.com?email=email
http://www.test.com?name=x
http://www.test.com?family=q
http://www.test.com?family=y
http://www.test.com?family=z
I can block requests that have a specific pattern by adding a pattern(for example the pattern *family* blocks 3 below requests):
http://www.test.com?family=q
http://www.test.com?family=y
http://www.test.com?family=z
Be careful! Because patterns are case sensitive
2. HTTP Request Blocker extension:
This extension has pattern matching for blocking requests:
Match patterns
3. Request blocker extension:
This is a useful extension that has pattern matching for blocking requests.
The most useful features of this request blocker are importing and exporting lists for using by other People.
For exporting a list and using in another computer(or future used): click on Direction down and select Export.
Open the exported list with import list button.
Good Luck
From Chrome 59 you can block specific requests from Network tab of developer tools itself.
https://developers.google.com/web/updates/2017/04/devtools-release-notes#block-requests
Right-click on the request in the Network panel and select Block Request URL. A new Request blocking tab pops up in the Drawer, which lets you manage blocked requests.
This is now achievable in Chrome 59 developer tools by blocking respective requests: https://developers.google.com/web/updates/2017/04/devtools-release-notes#block-requests. With this approach it is somehow difficult to turn off all the stylesheets, but it's easier to turn off just the most annoying ones.
As for Google Chrome 94, it's possible to exclude network activity for entire domain:
1. Go to "Network" panel of DevTools:
2. Rigth click on item of domain you want to block, click on "Block request domain" in the context menu:
3. Type "status-code:0" into "Filter" and click on "Invert" checkbox:
To manage blocked domains, press ESC button when in DevTools, and click on "Network request blocking" tab in the bottom panel:
Will changing host file help.
Your system (windows, linux, mac) all check host before requesting DNS lookup. I use it when I wan tot block some slow advertisers.
windows:
c:\Windows\system32\drivers\etc\hosts
linux & mac
/etc/hosts
* BE VERY CAREFUL TO MAKE BACK UPS *
An existing bug report is requesting this feature. You can star that issue to show support for it being added.
Well, i have been looking for an answer for this too, as I had this issue of choices by counterfeit, and nothing seemed to work for me.
But then I tried to analyze the requests and other things until I figured out, that there was this site which was loading ads onto my pages and redirecting me to advertisements. And also changing the google search bar on new tabs to some unknown search engine. I was able to temporarily block the request on one page. but after opening a new tab, the ads would appear again.
So googling for request blocker, I came up with a chrome extension "HTTP Request Blocker" and added the address which was causing all the crazy ads, has now solved the problem fully.
I hope it will be of help to you too or anyone else.
In the original question, the author states:
the famous blocking extensions only block URLs which the user enters manually into the navigation bar.
This is no longer the case. I have really enjoyed using mokku, which can intercept and mock all types of requests. You can specify what the status code should be, so it will definitely solve this problem as well as adding other functionality that is helpful. It works by another tab in the chrome dev tools. Here is a link to the extension: https://chrome.google.com/webstore/detail/mokku-mock-api-calls-seam/llflfcikklhgamfmnjkgpdadpmdplmji?hl=en
I'm trying to see a POST request that my browser is making on a certain form.
My problem is that the form is opened in a popup window (js initiated) and when the form is submitted it automatically closes the popup. So when I'm trying to use the developer tools' networking tab I can see the post request but don't have enough time to look into it since the window is closing too fast.
Even if I choose 'preserve log on navigation' it doesn't appear anywhere since the entire window is closing on submit.
Is there a way of opening the developer tools in the context of the entire Chrome application instead of a certain tab?
I don't believe there is. The best two solutions I can think of (that don't actually answer your question but I think achieve your aim) are:
Use another tool like Fiddler - http://fiddler2.com/ It's really good but only available for windows :(
It's a messy workaround but you could just comment out the line that closes the window while you carry out your debugging and then reinstate it once the issue is fixed.
We are currently using a meta refresh to initiate a download on a page, I read on Wikipedia that using this is not UX (user experience) friendly. So what is the way to have a download start after a few seconds when landing on a download page.
User interface-friendly way would:
Not spring an unannounced surprise to the user. So postpone the download by X seconds and clearly announce that.
This is done by setting up JavaScript logic to display a changing countdown to download. See below for details on implementation.
Allow user to control this by allowing immediate download
This is done by having the download timer announcement provide a widget (button or a link) to download immediately.
Keep the current page, by opening the download in a new window/tab.
The "kick off the download" logic should preferably be - instead of the obvious setting of window.location.href - something which opens a new window for the download. This way you allow the user to keep the main download landing page intact.
If possible, present a nice download widget
Instead of just pushing the URL of the download target, consider using custom download wisget like jQuery's jDownload plugin
To implement the changing countdown, do something like this:
Set up a variable for how long till download starts:
var DownloadIn = 10;
Set up a timer in JavaScript using setTimeout()`:
setTimeout("shouldWeDownload()", DownloadIn * 1000);
Subroutine shouldWeDownload() called from a timer will:
check if time period (stored in DownloadIn variable) is greater than zero.
If the time is NOT up (greater than zero), it will:
a. Check if a special "AlreadyDownloading" variable is set to true - this variable will be explained later. If true, simply exit.
b. print to a special DIV on the page - something very obvious and visible to the user - a message "XXX seconds left till the start of download. Click on this link to start the download".
c. Decrement DownloadIn variable
d. Set the timer again using the same setTimeout
If the time's up, kick off the download.
In addition, the "this link" link in the message would also immediately kick off the download. To make things clean, the "immediate dowload" onClick JS handler should set a special "AlreadyDownloading" variable which is checked in the logic above should be set to true, so we don't start a second download due to minor race conditions.
I don’t know of any research on what users expect, but I’d suggest mentioning that it’s a download in your initial download link, e.g.
Download my awesome track
(Maybe style that link like a big button, maybe even with an arrow pointing downwards in it: e.g. something like this.)
And then set your server to return that file with the Content-disposition header set to 'attachment' and the name of the file, so that the browser immediately lets the user know they’re downloading something:
Content-disposition: attachment; filename=kiss_from_a_rose__dubstep_remix.mp3
That way you don’t open a new page just to make the file download. The file downloads, the user’s still on the page where they were when it’s downloaded, everyone’s happy.
Fewer steps = fewer things for users to be confused by.
Using the browser’s UI = more chance that the user will have seen it before, and thus know what’s going on
unix user freindly? Depends entirely on the browser, and last time I checked, most/all linux browsers and safari worked fine with meta refresh.
Which is why most websites offer meta refresh with a download link.