Trouble with Omnibox in MV3

[Roberto Oneto]

Hi everybody,

I'm trying to migrate an extension to MV3.

I have some problem with Omnibox API returning an error inside the chrome.omnibox.onInputChanged listener.

Specifically, at the exact point where I call chrome.omnibox.setDefaultSuggestion.

The DevTools Console says:

Error in event handler: ReferenceError: DOMParser is not defined

    at parseOmniboxDescription (extensions::omnibox:24:19)

    at extensions::omnibox:92:23

    at updateDefaultSuggestion (chrome-extension://plnpjhdgkheejelmblnanljpgcifkcgn/script/main.js:1212:17)

    at chrome-extension://plnpjhdgkheejelmblnanljpgcifkcgn/script/main.js:52:14

    at extensions::omnibox:118:3

Has anyone already encountered a similar error?

This is my code:

chrome.omnibox.onInputChanged.addListener((input, suggest) => {

let descr = updateDefaultSuggestion(input);

if (input == '')

return;

if (isAnno && isIndic) {

annoV = pattA.exec(text)[0].trim();

indicV = pattI.exec(text)[0].trim();

regSelV = undefined;

let result = [];

let suggestion = {

content: '1',

description: descr + '  Visualizza i Grafici'

};

result.push(suggestion);

suggestion = {

content: '2',

description: descr + '  Visualizza la Scheda Indicatore'

};

result.push(suggestion);

suggest(result)

}

});

function updateDefaultSuggestion(t) {

text = t.trim();

isAnno = pattA.test(text);

isIndic = pattI.test(text);

let dt = new Date();

let y = dt.getFullYear();

let annoBrac = '20' + (y < 2020 ? '1' : 'Y') + 'Y';

let description = '<match>Beessy</match><dim> [ </dim>';

if (isAnno && isIndic)

description += '<match>' + text + '</match>';

else if (isAnno)

description += '<match>' + text + '</match> [Codice Indicatore]';

else if (isIndic)

description += '<match>' + text + '</match> [' + annoBrac + ']';

else

description += '[' + annoBrac + '] [Codice Indicatore]  |  [Codice Indicatore] [' + annoBrac + ']';

description += '<dim> ]</dim>';

chrome.omnibox.setDefaultSuggestion({

description: description

});

return description

}

Tnak you

[wOxxOm]

FWIW Simeon reported it in https://crbug.com/1186804

The problem is that service workers don't have DOM and hence no DOMParser. What's worse, I don't see small polyfills for DOMParser that also implement querySelector used by chrome.omnibox API internally. The complete polyfill from JSDOM is 5MB minified, but it wants to run inline JS so using it would require configuring/patching, which is an exercise for the enthusiastic developers who don't abhor the idea of including 5MB of minified js just to make Chrome's own API work :-)

[Roberto Oneto]

Thanks for the info wOxxOm,

When I saw "DOMParser" in the error description, an alarm bell immediately rang.

What can I say... at this point I stop here and wait a couple of months before continuing with this migration (just yesterday I discovered that chrome.notification is broken as well...).

As for the DOMParser object (which cannot be used in workers as a window object) I would like to have my say.

Google pushes for the migration to MV3 saying that it is to harden security (and in fact prevents remote code),

but at the same time recommends you to include third-party libraries in the extension package to overcome this kind of problem.

While I have no doubt that these libraries can be excellent and bug-proof, on the other hand I find the advice provided unprofessional.

It shouldn't be the developer who includes a 5 Mb library in his extension trying to keep all the functionality of his extension,

but it should be the browser to provide (inside the JS engine) a new object with the minimal functionality of DOMParser.

Alternatively, if Google claims these libraries are "super reliable", then it could whitelist and authorize them for remote scripting.

Best regards

[wOxxOm]

FWIW chrome.notifications is fixed in Chrome 91

[Roberto Oneto]

Hi,

I have installed Canary and now the image error when creating notifications no longer appears.

But now I'm having a problem with "progress" notifications.

This type of notification is created successfully, but then fails to update.

To be more specific, the first update is successful and I can see the bar advance, but from the second update the bar no longer advances.

I tested the code with the debugger but no error is thrown.

Has a similar problem already been reported?

[wOxxOm]

>  the first update is successful and I can see the bar advance, but from the second update the bar no longer advances.

Maybe you could show the code? My guess is it doesn't account for the fact that the background script terminates in 30 seconds.

[Roberto Oneto]

Hi, 

I made a micro extension made for use.

The creation and the updating of notification is not in backgrounf script.

I attaching also the specific code where I create and update the notification:

const numIndic = 10;

function someSecs() {

return new Promise((ok, ko) =>

setTimeout(ok, 2000 + parseInt(1000*Math.random()))

)

}

function go() {

var title, message, iconUrl;

var progress = 0;

var opt = {

type: 'progress',

iconUrl: '../img/wait.png',

title: 'Printing...',

message: '0 of ' + numIndic,

priority: 2,

requireInteraction: true,

progress: 0

};

chrome.notifications.create('Printing', opt, async function(id0) {

console.log(id0);

for (let r = 0; r < numIndic; r++) {

progress = (100 * (r + 1)) / numIndic;

await someSecs();

console.log('one step more...');

console.log(id0);

chrome.notifications.update(id0, {

message: (r + 1) + ' of ' + numIndic,

progress: parseInt(progress)

}, checkLastError);

}

console.log(id0);

chrome.notifications.update(id0, opt, () => {

opt = {

contextMessage: 'Done!',

iconUrl: '../img/pdfIco.png',

title: "Done!",

message: '',

progress: 100,

requireInteraction:false

};

chrome.notifications.update(id0, opt, () =>

chrome.notifications.clear(id0, checkLastError)

)

})

})

}

function lets_go() {

document.getElementById("go").addEventListener('click', go)

}

function checkLastError() {

if (chrome.runtime.lastError)

console.log(chrome.runtime.lastError.message);

else {

}

}

document.addEventListener('DOMContentLoaded', lets_go)

I just realized that this notification issue is off topic respect to the open thread title.

If necessary, I can open a new thread.

Thanks

[Roberto Oneto]

I just discovered a very weird thing.

The script works on Iron 88.0.4500.0

I see the percentage bar advance (with no image)

In Chrome Canary instead I see the first update step and then the other steps are hijacked in the Window 10 notifications tray.

Is it a normal behaviour?

[wOxxOm]

Your extension works for me both in Chrome stable and Canary so I guess the problem you observe is caused by a setting in your OS or by a bug in Chrome.

One thing though: if you move this code from a visible extension page such as your progress_bar.html into the background worker, note that it lives only for 30 seconds since the last API event like chrome.runtime.onMessage so if any setTimeout exceeds that, it'll never be triggered so in such cases you'll have to prevent the service worker from unloading by keeping a chrome.runtime port open (more info).

[Roberto Oneto]

Ok thanks for the advice wOxxOm

In the real case I use this type of notification always in a visible page of the extension.

Among one update and another there is not a setTimeout but an XHR \ fetch.

As you say, I think the problem lies on my pc, but I still haven't found his origin.

I did the same tests with my laptop that I use for work and whatever browser I use the problem does not recur.

Viceversa, on my desktop pc the problem occurs on any browser but Iron vers. 88.0.4500.0

At this point I begin to suspect that everything is due to a windows update which (in my case) took place just tonight (Italian timezone).

I add one last thing:

With the iron the notification looks like this:

while with the other browsers (Chrome stable, Canary, Edge) it looks like this:

Is the theory of windows update possible or is it the fault of my desktop settings ?

Thanks for any suggestion you want to give me.

[guest271314]

What is DOMParser needed for?

Messaging can be used to parse in a document and send results to Worker thread.

[Roberto Oneto]

chrome.omnibox.setDefaultSuggestion  internally uses querySelector and \ or other DomParser methods.

that's why this kind of mistake comes up

[hrg...@gmail.com]

I've also experience this problem with notifications under a recent installation of Windows 10.

The updates to a notification are not shown on the screen. Instead, all updates to a particular notification are coalesced into a single item inside the notification center of Windows 10.

This makes progress notifications entirely useless, as the user never sees the progress bar... progressing.

Since I don't use Windows 10 other than for testing purposes, I thought this inconvenient behavior was normal in Windows 10.

Apparently I was mistaken. Per your comment, I seems to be a new thing.

[Roberto Oneto]

Thanks for your evidence "hrg ... @ gmail.com"

In the meantime I connected remotely to a third win 10 pc and I tested the code.

I have found the same behavior (with the exception of Iron 88.0.4500.0)

I confirm that the first update is successful and the following ones end up in the notification area.

I also entered the keywords "notification update" or "notification progress" on bugs.chromium.org searching for a possible bug report  but I have not found anything relevant.

I ask you experts if I should report a new bug or it's better to wait for more user test\reports ?

EDIT:

I found an incredibly similar report on stackoverflow.com; it is 10 months "old".

This is the link:   LINK

[Roberto Oneto]

It seems that the notification updates issue is an already known issue that affects the Windows OS only.

There are two bug reports available:

bugs.id:1064558

bugs.d:1188338