Match "-" or just a part of subdomain in Chrome extension - google-chrome-extension

I have a specific problem with our environment, and I can't find the matching pattern for Chrome extension permissions.
The extension works exactly what it should, so no code needed here.
Problem is the following:
My main domain has following pattern:
product.com
test.product.com
uat.product.com
And I'm using extension on two complex pages '/page1' and '/page2'
But, I have another product (internal) that uses the following pattern:
internaltool.product.com
internaltool-test.product.com
internaltool-uat.product.com
Now, on the Internal tool, I use the extension on '/crazy/long/path/page3'.
Initially I had each of the page on main product stated in the permissions, and it worked fine. but then I tried to reduce the amount of manual work and I've added:
"permissions": ["contextMenus", "storage", "tabs", "https://*.product.com/*"],
Which now causes a minor cosmetic issue. On every other page on both products, I have an empty context menu that is confusing some people.
Is there a way to match words "test" and "uat" as well "internaltool+test/uat" without manually adding each single page to permissions?
I tried "internaltool-*.+product.com/*", which works on online regex tools, but chrome extension is giving me the "unknown pattern" error.
Of course - I have internaltool.product.com/page1 and internaltool.product.com/page2 as pages, so adding "*.product.com/page1" to permissions reduces the number of empty contexts only to these 2 pages on the internal tool, but it's not as good as it could be.

Related

Does a third party chrome extension affects a website's Cumulative Layout Shift (CLS)?

Let's say I have a website called "Example Website", and it has a bunch of paragraphs in it. Something like the image shown below
Now assume that there is a chrome extension out there which injects some images inside my page. These images are inserted without any animations whatsoever, causing a pretty bad layout shift in my web page. Here is what the page looks like after the extension has inserted the images.
So here are my questions,
Does the layout shift caused by this third party extension affect the CLS in my website?
What can I do as the developer of a web application to prevent such extensions from causing layout shift in my website?
What can I do as a chrome extension developer to not affect any other website's CLS?
Short Answer
Yes, extensions do affect CLS if they cause layout shifts.
There is nothing practical that you could do to stop an extension affecting your CLS.
If you are building an extension, you can limit CLS issues caused by your extension by using positioning that does not change the document flow (where possible).
And above all...don't worry about it too much, it is very unlikely you will ever cause or have someone's extension cause any CLS issues that will affect your SEO efforts etc.
Longer Answer
Does the layout shift caused by this third party extension affect the CLS in my website?
Yes!
If you use performance-observer on your page (which is the same API the CrUX data is built with) to measure layout shifts, you will see that these do contribute to your CLS.
What is not clear (or disclosed as far as I am aware) is whether Google have thought of this and take installed extensions into account on the data set they use for Core Web Vitals (CWV).
This is why whenever you run Google Lighthouse or a Performance Trace in your browser you should always go "incognito", so extensions do not affect your score.
What can I do as the developer of a web application to prevent such extensions from causing layout shift in my website?
Very little!
Extensions operate outside of your site control. Even if you tried to use Content Security Policy to limit script insertion (or similar) it is ignored.
You could try listening for requests using a service worker, have a whitelist of scripts, then delete or intercept any that do not match (I have no idea if this would even work for an extension FYI, just a thought off the top of my head!).
But at that point (assuming it works) you have created a far worse UX problem...you broke an extension I want to use as an end user and I will be annoyed.
The golden rule is to follow CWV as a guide...never do anything that hurts User eXperience just to please Google!
What can I do as a chrome extension developer to not affect any other website's CLS?
Not insert anything within the document flow.
So make your elements appear inside a container that is position: fixed for example (or any positioning that does not affect the original document's layout).
Other than that, yet again, I think you have very few options as you would normally want the page to have loaded before interfering with an extension.
The real question is...is it actually a problem?
I would argue it isn't.
If your extension causes layout shifts then a user is expecting that, so there is nothing you need to worry about there.
In terms of your site performance and CWV...unless a large proportion of your user base are using a misbehaving extension that happens to cause massive layout shifts you will not even notice!
Imagine a very unlikely "worst case" scenario: 10% of your userbase get a CLS score of 1 (which would be a complete page shift!) due to an extension.
Assuming your site has no layout shifts (CLS score of 0), then you will still only have a CLS average of 0.1 and that would still be a "good" rating (only just).
Then consider that CLS only makes up a small percentage of Web vitals scoring, and that web vitals scoring is only a small part of your SEO score...and you will see that it is very unlikely that you will see any negative impact.

documentUrlPatterns not respecting pathnames

I am running into some issues when attempting to use documentUrlPatterns with my web extension, on Safari, when creating context menu items.
Example:
browser.contextMenus.create({id: "12354", title: "Test01",documentUrlPatterns:["https://www.linkedin.com/feed/"]});
When using documentUrlPatterns on any website with an explicit pathname (as shown above), the context menu item does not get created for matching document urls.
With the above code I would expect to see a context menu item on https://www.linkedin.com/feed/ with the title Test01, but nothing appears. As mentioned, it seems any explicit path name, such as /feed/ or /someother/page/ on any website presents this issue.
My understanding of how matching works makes me think that explicit path names are valid in patterns, but perhaps I am missing something.
If I drop the last trailing slash /, the context menu item seems to be created as expected.
Is my expected outcome valid or is there something unique about the way documentUrlPatterns works that I am missing?
The above code seems to work as intended in Chrome and Firefox. I imagine this could be an Apple Safari related bug but before reporting it, I was curious if there's something I am missing.

View. Show values as Links. Strange behaviour

Xpage (listPostits.xsp) has a "View" container control, where one of the column is set "show values in this column as links".
Now, here comes "Strange behaviour".
When i work with this application on my own (developer) PC (Win XP, Chrome or IE), the Domino generate the link, which can't be really processed:
/servername/db/postit/postit.nsf/listPostits.xsp/onePostit.xsp?documentId=many_numbers&action=editDocument
Namely, the Bold-marked portion shouldn't be there ! This portion is the name of the XPage, where the View control is in.
When i work with the application from other PC (Mac, Firefox) then i get the correct link (the same as above but without the XPage name inbetween):
/servername/db/postit/postit.nsf/onePostit.xsp?documentId=many_numbers&action=editDocument
update: let us leave for the moment the differencies in generated links between two machines. The first question is - why the extra portion is inserted into automatically generated link?
After playing around i think i might have found the reason for this strange behaviour. Namely, the "Substitution" Rules on the server side. One of them is to substitute "*/postit/all" with "/db/postit/postit.nsf/listPostits.xsp"
If i switch it off, then the Links are generated properly. Still, it's pretty strange to me that these settings influence the way Domino generates the links. I thought it works on the fly with them and those settings have nothing to do with the way how Links are generated inside the application.
So, the help now is needed regarding Web Site Rule Topic, but for that, i guess, i have to create another topic. But in case somebody has some good Info on this, please share it with me. I'm a bit confused at the moment :)
Final Update: Spent some more hours of testing and the results confirmed the initial idea.
If i open the page with the standart URL, i.e.
http://servername/db/postit/postit.nsf/listPostits.xsp then everything is fine, links are generated properly. When i however open the same page with short URL http://servername/postit/all , then server adds the substitute URL (db/postit/postit.nsf/listPostits.xsp) to every single link he generates automatically to be used as the link to open/edit the underlying document.
Is it bug or feature ? Don't know.
As a workaround (because i want to keep simple URL's for the application) i have to manually generate links.

Working example of og:audio:artist and og:audio:album

Can someone identify ONE WEB PAGE where <meta property="og:audio:artist"> and <meta property="og:audio:album"> are actually working to set the Artist and Album when sharing the URL of the page?
I have been banging away at http://www.coises.com/songs/sfcarol.htm for hours, trying every permutation of order of META tags, XML tag formats (even though it’s an HTML page), etc. (Note: though I have a home-grown share button on the page, I’m talking about sharing the URL of the page in the status box on Facebook itself as the test case.)
All I can get is that all words in the title are capitalized, even though it isn’t specified that way, and the Artist and Album are always Unknown. (For another song/page, "8/9/95", even the title won’t show.) The description also doesn’t show when doing the share, though it does show in the posted story.
I tried searching, and I tried places like ReverbNation and SoundCloud, but nobody seems to use the og:audio tags. (For videos, copying the way YouTube does it appears to work perfectly, http://www.coises.com/songs/risingup.htm being an example.) If I could see just one working example, I suspect I could figure it out.
My own song pages (e.g., http://www.coises.com/songs/floodplain.htm and most other song pages on my site) are now working examples.
It turns out the problem was simple: og:audio:artist and og:audio:album do not work unless og:audio:title is also supplied. I had assumed that would default to og:title; it seems it must be explicitly specified.
The linter still says the og:audio:{title|artist|album} tags are not allowed, but they work.
Those OG tags still seem to be in beta. below I've included the linter results for five different websites that facebook is in partnership with.
https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fmog.com%2Fm%2Ftrack%2F57587005
https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fwww.deezer.com%2Fmusic%2Ftrack%2F6461440
https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fwww.rhapsody.com%2Fartist%2Ftrombone-shorty%2Falbum%2Ffor-true
https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fwww.vevo.com%2Fwatch%2Fj-cole-featuring-trey-songz-j-cole-1%2Fcant-get-enough%2FUSQX91101318
https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fopen.spotify.com%2Ftrack%2F3ssX20QT5c3nA9wk78V1LQ

How do I hide Drupal nodes that shouldn't be directly accessed from users and search engines?

I have seen many somewhat similar questions, but nothing quite what I'm looking for. So at the risk of being told this is a duplicate... here it goes.
I've found that there are times I have a node that simply contains content that will be displayed somewhere else, but shouldn't be viewed directly. That is, no one should ever go to node/1234, but the content in node 1234 should be displayed somewhere else.
For example, I create an about page with tabbed content using views. So there are "About Me", "About Us" and "About Them" pages. All of these are displayed in a single page with tabs using Views. So I don't want people to get directly to the "About Us" node because then they wouldn't see the tabs for the other pages. At the same time, I don't want Google giving people a direct link to this node, I want to limit access so users can only get to it through the View (i.e., the tab).
So I need to restrict access to the node, remove it from the Drupal search results, and make sure Google doesn't pick up on it. Any suggestions?
---- Note ----
I've accepted the answer from mingos (thanks btw) because even though it's not a full answer / solution, it gave me some good things to think about. Additional answers are still welcome.
In Drupal 7 you can use: http://drupal.org/project/internal_nodes
Description: Some content/nodes should never be viewed directly; only visible be through something else such as Views or Panels. This module denies access to node/[nid] URLs while allowing the content to stay published and otherwise viewable.
Full disclosure: I am the creator and co-maintainer of Internal Nodes. I found this question while searching to see how the module could be found on Google.
Tough one.
If you want to have many nodes like this and do the "displaying elsewhere" dynamically, I can't think of anything right now (at 2:20 AM I rarely can).
If there is onne such page (or very few), I'd restrict access to it by any available means (Permissions, Nodeaccess, Content Access, TAC, whatever) and then create special themes for the pages where the restricted content should be displayed. The themes would contain database queries, fetching content from the restricted nodes.
Other possibility might include creating a special theme for the hidden nodes in question (perhaps all belonging to the same content type?). Make full node display nothing (or a message saying the access is restricted) and add a ROBOTS meta tag asking Google not to index the page. Make the teaser view available though - you can display it freely inside a view, but since /node/1234 is the FULL view, the actual content will be unavailable here.
Dunno if this solves your problem, hope it helps at least a bit.
I found this page after running into this same problem.
What I found worked for me might be part of the answer you need:
Take a look at the Page Manager Redirect Module http://drupal.org/project/page_manager_redirect . I just started playing with it.
It uses the Page Manager module of CTools to redirect one page to another. What makes this most powerful is that Page Manager uses Contexts. So, if you want to redirect all pages of a particular content type, you can do so.
I just started to use it (instead of Taxonomy Redirect and Path Redirect) to redirect (301 response code) my taxonomy terms for a particular vocabulary to particular nodes.
In your instance, you should be able to use contexts to filter for specific pages.
Of course this doesn't solve the problem of these nodes coming up in search results.
There is also another module Rabbit Hole which has a similar functionality like Internal Nodes but works for all entities, not only nodes.
I am having the same problem, and are currently thinking of the following solution where all the content of a node is to be displayed to certain users (permission based):
- unpublish node
- create a new published checkbox
- create a view with fields that shows alle the content
Haven't tested it thoroughly yet, but it seems to work.
The node is to be displayed to the creator (only one in permission 1), some of it to permission 2 and all of it to permission 3.
Any comments on this solution.
I assume this will also exclude it from search, but permission 2 and 3 needs to be able to search it. Still haven't figured that one out.
I used Rules module with an "entity is of bundle" and the built-in "Page redirect" action.
There is a really easy way to do this if you only want to show a content type through a view.
create a content type as and make it unpublished.
create a view and on the filter option set the filter to "Content: Published (No)"
the view will give anon users access to the content through the view but they won't have access to the unpublished content at the direct link to the content.

Resources