Re: [crx] Digest for chromium-extensions@chromium.org - 11 updates in 6 topics

47 views
Skip to first unread message

Dora Jimela Kialo

unread,
Oct 7, 2021, 9:37:40 PM10/7/21
to chromium-...@chromium.org
Hello all,
I am also having trouble accessing 402 and 404
Please help
Dora Jimela Kialo
MEd Lead
A/Director- TLMU, The Papua New Guinea University of Technology


On Fri, 8 Oct 2021 at 00:03, <chromium-...@chromium.org> wrote:
Vladimir Yankovich <yankovic...@gmail.com>: Oct 06 07:16AM -0700

Zela, hello. I am also making a new tab, I will be glad to meet and
exchange experiences :)
 
Cuyler Stuwe <salem...@gmail.com>: Oct 06 10:00AM -0700

TL;DR — They don’t want things like Bonzai Buddy and WeatherBug.
 
They want your extension to have a clear purpose, so that it’s easier to
tell when it’s doing something that it shouldn’t (e.g., there’s no reason
that a golf game needs to inject content script code looking for password
fields).
 
Don’t overthink it.
 
On Wed, Oct 6, 2021 at 7:16 AM Vladimir Yankovich <
Marcus b <mmga...@gmail.com>: Oct 06 03:26AM -0400

Jackie Han <han.g...@gmail.com>: Oct 07 09:48PM +0800

See What does "single purpose" actually mean?
<https://developer.chrome.com/docs/extensions/mv3/single_purpose/#three>
 
It says "new tab page" is a browser function. So "new tab page" can have
lots of different functions, but they *must be supplied* in the new tab
page.
 
Vladimir Yankovich <yankovic...@gmail.com>: Oct 07 06:52AM -0700

Jackie, you're right. But it seems that the example at the end of the
document matters more.
 
This is an important example, which shows that this policy, in fact, does
not impose any strict restrictions, except for the common sense of the
moderator :)
 
[image: Extensions quality guidelines FAQ - Chrome Develop.png]
On Thursday, October 7, 2021 at 4:49:03 PM UTC+3 Jackie Han wrote:
 
Carlos <keganlanc...@am22i6xaf1m2a5m9k.xyz>: Oct 03 03:23AM -0700

@Jackie Han Using navigator.language or chrome.i18n.getAcceptLanguages is
not gonna provide the same result. As chrome.i18n.getUILanguage and
chrome.i18n.getMessage use the language of the browser itself. Not the
languages websites are requested in.
 
In addition, going for a fetch to _locales won't consider language
fallbacks. Currently getMessage can go from es_419 to es to en. And many
webextension authors make use of this fallback mechanism to reduce the
extension package size.
 
Supporting chrome.i18n.getMessage has been proposed in the w3c webextension
group. See:
https://github.com/w3c/webextensions/issues/93
 
Jackie Han <han.g...@gmail.com>: Oct 07 09:30PM +0800

Carlos,
 
So I said it's a *workaround* method (if there is no other way), and didn't
say it is exactly the same implementation mechanism.
 
The browser UI language is usually the language of the operating system or
specified by the browser's startup parameter.
 
navigator.language(s) is also usually the languages of the operating system
by default and users can customize them in the browser
settings(chrome://settings/languages). This is also used for the
Accept-Language HTTP header.
 
Although navigator.language may be different from the browser UI language,
it is still an *acceptable* language for users.
 
Compared with the front pages, the service worker or background
page usually requires a small number of messages. So developers can write
messages in JS code directly if they don't use chrome.i18n.getMessage() .
 
By the way, chrome.i18n.getMessage() can't support passing a preferred
language as a parameter. If you want to let users change your extension's
language independently (don't change browser UI language or OS language),
you can't rely on chrome.i18n.getMessage().
 
On Sun, Oct 3, 2021 at 6:23 PM Carlos <
Dream Kuang <shuha...@gmail.com>: Oct 07 06:25AM -0700

I also encountered this situation, which really makes it hard to understand.
My extension is token down.
 
On Wednesday, 6 October 2021 at 7:44:32 pm UTC+8 GroupNinja Official wrote:
 
Lawal Sanusi <xla...@gmail.com>: Oct 07 12:37AM -0700

Hello
 
We can navigate to this extension link from our website (joinsmartcart.com)
using a desktop;
https://chrome.google.com/webstore/detail/smartcart/hkckdnfadmnkgmkojfhdihollnjhlaam
 
However we keep getting 403 error from any mobile device. We have tested
with users and multiple real devices on browserStack and still getting same
issue. However we can access links from other extensions on chrome store
without any issues via the same website. The problem is just with our own
link to the store.
 
We recently renamed the app from Smartify to SmartCart and now wondering if
that could be root cause?
 
Kindly assist.
 
 
 
Thanks
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
@dotproto
Simeon Vincent <sim...@chromium.org>: Oct 06 04:48PM -0700

If you haven't already, I'd recommend reaching out to Chrome Web Store
Developer Support
<https://support.google.com/chrome_webstore/contact/one_stop_support> to
request assistance with this issue.
 
Simeon - @dotproto
Chrome Extensions DevRel
 
Simeon Vincent <sim...@chromium.org>: Oct 06 09:34AM -0700

Thanks for raising this, Hao.
 
We intend to provide extensions with a way to fetch extension icons from
within a background service worker, but the exact mechanism is unclear at
the moment. After a quick conversation with the eng team, the two options
that look most promising at the moment are:
 
- Expand fetch() to support chrome:// (as well as file://) schemes in
extensions
- Provide support for extension icons as part of the new favicon API
 
It's also possible we may explore other options or a combination. At this
point it's simply too early to say. I've opened crbug.com/1257227 to track
this issue.
 
Simeon - @dotproto
Chrome Extensions DevRel
 
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to chromium-extens...@chromium.org.
Reply all
Reply to author
Forward
0 new messages