I have made a chrome extension with the name Newsprompt : Personal Breaking News(gcajgpbafhkbkdpbaaipjoiajnangjhp) is recently being taken down stating that it breaks "single purpose Chrome extensions policy". It shows the breaking news in new tab and keep learning about user preference to push the articles(not news) user is interested in. No adds, no hidden functionality. That is all the extension does. Since it has been taken down, I have constantly been following up with
chromewebstore-dev-support#google.com and removed a lot of features (personalization being one of them) but all they come back with exactly same copy pasted lines from the docs https://developer.chrome.com/extensions/single_purpose that it doesn't comply with their standards. It feels like talking to a bot whose only response is "it doesn't comply with standards". So my question being:
1. Has any developers faced the same issue? (I have seen a couple of developers complaining on google groups but no one getting a solution). If yes how did they solved/escalated the problem (It felt like wasting 6 months of my team's effort for nothing).
2. I have tried https://support.google.com/chrome_webstore/contact/developer_support but no response.
3. Any further leads will be appreciated.
Related
I am encountering a really strange behavior with Google Chrome.
In the Google Chrome Address Bar (where you can type in search term or URL), it will remember the history of the search and pages. However, when I run a "clear all history." It cleared almost everything except a few URLs and a few searches. This makes those few histories in the address bar "undeletable".
Since it is synchronizing this across my devices as well, the undeletable entries (less than 6 entries) also appear in my mobile phone Chrome as well.
Here's what I've done (with my Google Account logged in using Chrome)
Clear history in Chrome with time range All time and select Browsing history & Cookies and other site data
Go to myactivity.google.com/myactivity and click on Delete activity by and choose All time, and for products, I only checked Chrome, Search.
Restart the browser
At this point, when I type something into the Chrome address bar, the undeletable entry still shows up.
Any idea what am I missing?
This shouldn't be this difficult, but I couldn't figure it out and did a lot of searches online, cannot really find a solution to this.
Any help will be fantastic!
OK,
I figured it out. I'll leave my answer here so other people who encounter this similar problem know what's going on.
Basically, the Google Chrome address bar will auto-complete history AND any bookmark that you have.
So that means when I clear all "history" (which it did clear successfully), but if I have it in my bookmark, it will still show up in the address bar auto-complete option.
So regardless of how many times you clear history (which once is enough), as long as you have it "bookmarked", it will show up. There's no easy way to tell if the suggestion is a "bookmark" or a "history".
If you are in the same situation, I hope this answer will help you.
Thank you!
In pre v9.5 websites I used realurl.
When you change the site-title from tileV1 to tilteV2 the page could be accessed with domain.tld/titlev1.html AND domain.tld/titlev2.html.
The realurl path of titlev1 was marked as MovedPermanent (and redirects) to titlev2 and an expire date for the v1 is sent to the browser (+30 days).
My editors don't care a lot about SEO and the rest. They copy pages, deleting the content, moving them around the pagetree - nobody cares about the slug, often this is default-titlexx.html.
With realurl this was less painful compared to the native URL-handling in TYPO3.
I could not find any documents/websites discussing the problem.
Am I missing some option to set? How do you solve this?
Training the editors to double check the slug, but this only works for 2 days then I get the next error report: The page is broken cause a page has moved...
Thanks for any help in this issue!
There are some differences between TYPO3 9 and 10. In 10 you have additionally functionality which handles this:
when changing a slug, TYPO3 offers to change the slugs of the subpages - the editor gets a choice to do this or not
redirects will get created automatically, here you also have the choice to allow redirects for subpages as well.
You might also want to look at the extensions that are available for TYPO3 9 which try to enhance the Slug handling, e.g. sluggi. (I have not used this myself, but it looks like it may be helful).
There are also a number of open issues about Slug handling and redirects.
What I would recommend
Think about updating to 10. There are not quite so many breaking changes and you might find the update quite painless. Or look at the slug extensions.
Familiarize yourself with the slug and redirect handling (in v10). (Yes, the documentation may be incomplete but a lot of it is self-explanatory. Just test changing Slugs on some pages with subpages and move a page and the functionality should reveal itself).
Using permissions (possibly also workspaces) you can restrict what editors may do. You might also want to restrict editing to some pages (e.g. editlock, permissions). If they can't handle something responsibly, maybe they should only have restricted access. (I realize this is not so easy to solve, we have the same problem and defining very fine-grained permissions makes it impossible to handle at some point. Also, the editors should be able to create new pages).
Sorry, I don't have all the answers right now. To be honest, our site is a little messed up in this respect currently, because of using TYPO3 9 for a while and not handling this problem. At some point, the URLs of subpages start to deviate and then it is difficulty to get it cleaned up.
What is better now, though: In realurl the editors often did not fill out the URL segment and then the URL changed every time the page title changed. This is now handled in a better way, I think, where you explicitly have to define the URL.
I want to implement web push notification in my application, however I'm stuck at very simple problem: is there anywhere on the internet resource which would give me complete table for characters limits in web push notification for notification title and body for different browsers/operating systems (I'm interested in Android/Windows 10/macOS and Chrome, FireFox, Safari, Edge, Opera and Yandex browsers)? I've spend quite a lot of time looking over various pages on the internet, however data I encountered there was either incomplete or not up to date or event mutually exclusive between various resources.
Any help will be greatly appreciated.
You don't find any information, because the standard doesn't set a limit.
The text, when too long, is automatically truncated by the browser. The actual limit depends on many variables: the OS, the browser, the layout, the presence of notification fields like images and action buttons.
The only actual limit is the total payload (which includes all fields and the JSON): you should stay below 3kB.
Update: I have made some research for you on the practical limits for each browser and published the results in this blog post.
UPDATE - 2/26/2020
One of our clients just got this back from Microsoft:
Thank you for submitting this issue to the Outlook for iOS and Android team. After careful consideration, the product team is maintaining it's decision to disable HTML within Outlook Mobile deeplinks. While HTML within deeplinks was previously allowed, support for this scenario was never formally designed or introduced. Additionally, supporting HTML within deeplinks can introduce unintended consequences and potential security issues.
Though not officially supported, deeplinks that utilize plain-text will continue to work in Outlook for iOS and Android. Please note that this behavior may be modified at any time without notice.
Using the UIActivityViewController to share your HTML body also no longer works. It would appear that Microsoft has taken away our ability to generate any HTML bodies when composing an email in their system.
UPDATE - 2/6/2020
As responses show, it's gone from fixed to broken again. One of our large custom app clients that uses outlook exclusively has been pursuing a ticket with MS and this week finally got a response that multiple companies have reported on this issue and they are looking into a way to securely allow sharing of HTML bodies. In the interim for iOS apps we've been converting our code to use the UIActivityViewController and excluding almost all the activityTypes. This allows you to set the HTML body:
let items = [["Body" : emailBody]]
let acv = UIActivityViewController(activityItems: items,
applicationActivities: nil)
The two issues with this approach, is
a) If you try and set the subject or recipients, those are ignored. I've tried multiple different ways with no success. So in the case of our apps where for reporting purposes we collect the contact info before the email is sent, the user is required to again enter the contact info in the Outlook message composer.
b) It adds an extra step of requiring the user to select Outlook as the share item from the Initial UIActivityViewController. We've had to deal with reported "bugs" that are not bugs, just users not selecting Outlook.
UPDATE - 12/12/2019
The issue appears to have been fixed by Microsoft as my Outlook version remains 4.15.0 but when asked today to make screens shots for a ticket I submitted, the links are now being encoded correctly again. Please vote to close.
Original Question/Issue
I was previously using instructions based on this post. But it appears that with Outlook for iOS version 4.14.x and up (Outlook version tested as of this post 4.15.0) the encoded HTML body is being stripped of all of its encoded characters. Which is to say that something like:
<br>
Some Link
<br>
Becomes
braref=www.somelink.comSomeLink/abr
Hoping someone from the iOS Outlook team sees this post and can perhaps provide some guidance on how one might configure an HTML body to be passed through the ms-outlook://compose body parameter. Or if anyone else has figured it out. Please respond.
Thanks!
In v4.19.0 (latest version) "less than" and "greater than" signs (< >) are back but the html body is not rendered, so emails looks like this:
<html><body><p><strong>Hi</strong>, how are you</p></body></html>
We have seen this go from fixed to unfixed, etc. Some days it seems to work and other days it does not. Today it seems broken again.
Starting this afternoon, with the introduction of Chrome 31.0.1650.48, many web pages are displaying with random formatting errors. I've confirmed this on both Mac and Windows machines running the most recent auto-updated Chrome release (31.0.1650.48).
This problem is affecting thousands of pages, and to immediately rule out our server generating different information, you can try this to reproduce the problem:
Visit this Google cache page with Chrome version specified above: http://webcache.googleusercontent.com/search?q=cache:nt70v_rn5BwJ:alaskanmalamute.rescueme.org/Idaho+&cd=61&hl=en&ct=clnk&gl=us
Notice what dogs are displayed and where they are.
Reload the page several times and observer closely.
You will randomly see one dog listing in the middle of the page, then two dog listings, the dogs move around, the menus around the dogs move around. Each time the page is reloaded Google is corrupting the source code in different ways, resulting in major formatting issues. (NONE of this code is generated outside of Google's cache.) All the pages on the www.RescueMe.Org have this problem, I'm using a cached page on Google's server in this article for an example since it proves it is not a server issue.
This sample page should remain the same every time, and be formatted correctly. It isn't.
Google Chrome (when viewing source) seems to be making random changes to the page (Chrome is dropping < or > at random places in source code) causing major display formatting issues.
Can someone reproduce this? Hopefully the folks at Google know about this issue, or someone here can escalate it with them?
Best wishes,
Jeff
can confirm - it seems to mostly be an issue with iFrames.
VisualForce iFrames in Salesforce break the entire layout.
Version 31.0.1650.48 on Mac, all addons removed.
In case someone else runs into this issue, I've narrowed it down somewhat. Chrome/31.0.1650.48 will randomly scramble the placement of tables on a page if the following two things happen:
1) You start the page like this: and do the reverse at the end: (doesn't have to be face=arial, any font setting or even just does the same thing).
2) Include some tags within the page containing various tables.
3) Magic! (not good magic, though) Each time your tables will randomly move about the page. Here's an example to try: http://server1c.rescueme.org/testb (Reload this page several times in in Chrome/31.0.1650.48 on Windows or Mac to see the tables jump around.)
THE SOLUTION: Start the page like this instead: and do the reverse at the end: (in other words, reverse placement of the center and font tags). Here's the "fixed" version of the page above with just those tags reversed: http://server1c.rescueme.org/testbfixed
While this is a Chrome bug, I feel this is worth keeping in Stack Overflow because this bug is breaking a lot of major sites, and programmers may want to know how to reprogram their HTML so those who have affected versions of Chrome won't have a confusing experience.
FYI... There are other ways to cause and solve this problem, but I'm trying to present here just the simplest method I found.