How To Change Pop Up Blocker In Chrome
Hanry Moreno
There is a new discussion or issue in Google Chrome development about a proposed change to the extensions system in Google Chrome / Chromium development.
In a nutshell, the suggested change would break the functionality of most, if not all popular ad-blocker extensions in Chromium, which the developers of these extensions have been pointing out to the development team. (source: -extension-manifest-v3-may-break-ublock-origin-content-blocker/ )
Why do I bring this up here?
Well, since ad-blocking is one of the essential features of Brave, and Brave is now forking Chromium, this might become an issue if Brave continues to implement changes made to Chromium.
I am hoping someone can help/has had this strange issue themselves. We are currently on CRM 2013 Spring Release in the cloud. We access CRM using Chrome version 40. We have 180 plus users across sites and currently 30 in my site.
We have 1 user (only 1), who intermittently gets the Chrome Popup Blocker message when they try to add an appointment from an activity Sub Grid on the Contact Form. The thing is we have allowed pop ups from CRM, and added the correct URLs to the various Allow settings. What seems strange is it will work fine for a number of hours, then suddenly, all he gets is the message. Restart Chrome and it goes away sometimes for a minute or two, sometimes for hours. He is only using Chrome for CRM no other browsing.
The message reads: A Microsoft Dynamics CRM window was unable to open, and may have been blocked by a pop-up blocker. Please add this Microsoft Dynamics CRM server to the list of sites your pop-up blocker allows to open new windows:ORG.crm4.dynamics.com
We found the issue, it was happening when the user had moved away from their main window. For example, opened up Chrome, added an appointment (which open a 2nd window), they added their note, but then used the 2nd window to go back to their dashboard and accounts. Because they had 2 windows open they then where closing the first. The second time they add an appointment it was from this 2nd window which opened up a 3rd. For some reason Chrome then does not allow the pop ups. I think it is because it is a window of a window.
We are experiencing the EXACT same issue - just one user has this happen to her when she tries to add activities from a subgrid. She uses chrome, but so do I. We have gone to the browser pop-up settings and made an exception for CRM (I have this too) - but it still doesn't work for her. And same issue. Sometimes it works fine, but once it starts popping up - nothing stops it unless she does a restart, and then it will work for a couple activities and start up again.
Thank you for the reply, however we have tried all this. We have all the fields and URLs in the various expection lists. The issue is, it works fine then every now then, Chrome has a paddy and says No. :-)
4) Under Pop-ups, click Manage Exceptions. In the Hostname Pattern box, type the URL that you use to access Microsoft Dynamics CRM. Your Microsoft Dynamics CRM URL will end in "dynamics.com". In the Behavior drop-down list, select Allow.
Manifest V3 changes how extensions handle modification of network requests. Instead of intercepting network requests and altering them at runtime with chrome.webRequest, your extension specifies rules that describe actions to perform when a given set of conditions is met. Do this using the Declarative Net Request API.
The Web Request API and the Declarative Net Request APIs are significantly different. Instead of replacing one function call with another, you need to rewrite your code in terms of use cases. This section walks you through that process.
In Manifest V2, blocking web requests could significantly degrade both the performance of extensions and the performance of pages they work with. The webRequest namespace supports nine potentially blocking events, each of which takes an unlimited number of event handlers. To make matters worse, each web page is potentially blocked by multiple extensions, and the permissions required for this are invasive. Manifest V3 guards against this problem by replacing callbacks with declarative rules.
This is the second of three sections describing changes needed for code that is not part of the extension service worker. It describes converting blocking web requests, used by Manifest V2, to declarative net requests, used by Manifest V3. The other two sections cover updating your code needed for migrating to Manifest V3 and improving security..
Creating declarative net request rules requires adding a "declarative_net_request" object to your manifest.json. The "declarative_net_request" block contains an array of "rule_resource" objects that point to a rule file. The rule file contains an array of objects specifying an action and the conditions in which those actions are invoked.
The following sections describe common use cases for declarative net requests. The instructions below provide only a brief outline. More information about all of the information here is described in the API reference under chrome.declarativeNetRequest
For Manifest V3, create a new declarativeNetRequest rule using the "block" action type. Notice the "condition" object in the example rule. Its "urlFilter" replaces the urls option passed to the webRequest listener. A "resourceTypes" array specifies the category of resources to block. This example blocks only the main HTML page, but you could, for example, block only fonts.
To make this work, you'll need to update the extension's permissions. In the manifest.json replace the "webRequestBlocking" permission with the "declarativeNetRequest" permission. Notice that the URL is removed from the "permissions" field because blocking content doesn't require host permissions. As shown above, the rule file specifies the host or hosts that a declarative net request applies to.
For Manifest V3, use the "redirect" action type. As before, "urlFilter" replaces the url option passed to the webRequest listener. Notice that for this example, the rule file's "action" object contains a "redirect" field containing the URL to return instead of the URL being filtered.
This scenario also requires changes to the extension's permissions. As before, replace the "webRequestBlocking" permission with the "declarativeNetRequest" permission. The URLs are again moved from the manifest.json to a rule file. Notice that redirecting also requires the "declarativeNetRequestWithHostAccess" permission in addition to the host permission.
Manifest V3 also does this with a rule in a rule file. This time the action type is "modifyHeaders". The file takes an array of "requestHeaders" objects specifying the headers to modify and how to modify them. Notice that the "condition" object only contains a "resourceTypes" array. It supports the same values as the previous examples.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
I have a couple of summary blocks set up to scroll through "Laurels" and "Testimonials" on my website, however, the default white coloured next and previous carousel arrows can't be seen for the Laurel summary block since the section background is also white.
I ended up using a chrome plugin called the "block identifier" to give each summary block its own unique code, allowing me to style the colour of the arrows for each specific summary block in the Custom CSS section.
I managed to change the colour of the arrows so they are now visible, but the left arrow in the Testimonial summary block has changed to the same colour as the ones I have altered in the Laurel summary block. Now there is a red left arrow and a white right arrow. I can't seem to fix this at all. I don't know if it's a bug or if I'm doing something wrong.
For several years now, Google has wanted to kill Chrome's current extension system in favor of a more limited one, creating more restrictions on filtering extensions that block ads and/or work to preserve the user's privacy. The new extension system, called "Manifest V3," technically hit the stable channel in January 2021, but Chrome still supports the older, more powerful system, Manifest V2. The first steps toward winding down Manifest V2 were supposed to start January 2023, but as 9to5Google first spotted, Google now says it delayed the mandatory switch to Manifest V3 and won't even have a new timeline for a V2 shutdown ready until March.
The old timeline started in January 2023, when beta versions of Chrome would start running "experiments" that disable Manifest V2. This would move to the stable version in June, with the Chrome Web Store banning Manifest V2 extensions in January 2024. The new timeline is that there is no timeline, and every step is now listed as "postponed" or "under review."
Google's statement only addresses the second controversial change to Manifest V3: turning off an extension's ability to launch a hidden background page due to background processing. Google wants all background processing to happen in service workers, but that's a complicated environment compared to normal web development and comes with many more limitations. Google's delay is only about trying to fix some of these background limitations.
Google's post does not mention filtering add-ons, so it does not sound like the world's biggest ad company is having a change of heart about ad blockers. The big problem for those extensions is killing the "WebRequest API," which allows ad blockers and other filtering tools to modify Chrome's network requests on the fly. Usually, this is used to create huge lists of websites (ad servers) the extensions want to block access to. Google has sort of thrown these extensions a bone by creating a new API that allows for a limited list of URL blocking, but this is only a static list of 30,000 URLs, while a typical uBlock Origin install comes with 300,000 dynamic filtering rules. Some ad blockers will try to play within these rules with the Manifest V3 version, but Google's going to erode their effectiveness and doesn't want to implement any of the common-sense solutions that would allow them to keep functioning at the current level.
d3342ee215