chrome.tabs.query doesn't have any way to differentiate between discarded and frozen tab due to which executeScript doesn't run

[piyush gupta]

Hi, I had posted a bug on chromium issue tracker almost an year back (https://bugs.chromium.org/p/chromium/issues/detail?id=1429905)

regarding how `chrome.tabs.query doesn't have any way to differentiate between discarded and frozen tab` and because we can't differentiate a frozen tab from a normal tab, when we run executeScript on such a tab, it just gets stuck.

I've added reproducible steps there on the bug, but still project members have found it hard to follow them.

Posting here to get help because the support page says `If your bug has not been modified after two weeks, please post a message to the Google group with a link to your bug.` and for this bug it has been around an year without progress.

[hrg...@gmail.com]

The problem is that your reproduction steps are too complicated.

Try making a simple extension packed in .zip format so that the tester can install it just by dragging it to the chrome://extensions page.

Also, I would say that the actual bug is that chrome.scripting.executeScript never returns when the tab is frozen. Instead, you made your bug report look like a feature request by asking that the tab info includes an additional property.

[hrg...@gmail.com]

By the way, this bug https://crbug.com/1326295 is almost the same except it happens with protected pages instead of frozen pages.

[piyush gupta]

Thanks for the feedback, I've added a new extension on the issue with the new comment and just focused on executeScript not running. I couldn't cut down much on steps because many of them seemed necessary.

Though I think even the original steps were not that complicated, but I just want resolution, so happy to help.

[Oliver Dunk]

Hi Piyush,

Thanks for reaching out about this.

I was able to confirm the issue and it does seem interesting. I'm unsure what the best behaviour would be here - since the script does run when the document is unfrozen, it seems to be working somewhat reasonably. I definitely agree this is hard for a developer to work with in practice though.

You could also consider opening an issue in the Web Extensions Community Group (https://github.com/w3c/webextensions) as this may be something we want to discuss alongside other browser vendors so we can have a common approach for situations like this.

Thanks,

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/3582d75b-6115-4aaa-bb62-007d96e2df10n%40chromium.org.

[hrg...@gmail.com]

The obvious solution here is that executeScript must return an error in chrome.runtime.lastError. Both bugs (https://crbug.com/1326295 and https://crbug.com/1429905) would be fixed with that improvement.

[piyush gupta]

Thanks Oliver for confirming on the ticket that it could be reproduced.

I have added an issue on web extensions group here as suggested.

[Simeon Vincent]

Hmmm. IMO erroring makes sense in the case of a protected tab, but it doesn't make sense when a tab is frozen. As Oliver said, "the script does run when the document is unfrozen." In that case, the injection was successful. It also makes sense that the promise returned executeScript doesn't resolve as execution hasn't occurred yet.

I see how a "frozen" flag on tabs.Tab instances would help here. I imagine it would also be useful for other tools, such as tab managers or diagnostic utilities. That said, for the case of trying to inject scripts into a tab, I wonder if it would be better to have a flag that signals whether or not the tab is currently executing scripts. That might also be useful for cases where a page has been cached in BFCache and provide some future-proving against other page states that may be introduced in the future.

Simeon - @dotproto

incremental.software

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/2c5a2ccb-fb66-4ea5-9d8d-0005d3540877n%40chromium.org.

[piyush gupta]

I don't understand completely the difference b/w unloaded/discarded/frozen tabs but I think erroring in case of frozen tabs would be consistent with how it is handled currently for discarded/unloaded tabs. As it throws error for the other two cases.

And although I did suggest adding a frozen flag initially but I think it might be even better to just have kind of an enum to signify a tab's state like tabState = 'frozen' | 'discarded' | 'unloaded' | 'othersWhichIDon'tKnow' so that devs can take their call on how to handle each state. 

Imo, the above approach is more scalable than adding a flag specially for executeScript because then the Tab object gets tightly coupled with executeScript. Instead of this, Tab object should just define the current state accurately with as much granularity as possible to empower the devs.

[hrg...@gmail.com]

On Saturday, January 20, 2024 at 12:35:35 AM UTC-3 Simeon Vincent wrote: 

As Oliver said, "the script does run when the document is unfrozen." In that case, the injection was successful. It also makes sense that the promise returned executeScript doesn't resolve as execution hasn't occurred yet.

More importantly is the fact that execution may never occur because a tab can be frozen indefinitely until the user closes the browser or it may occur at a time the programmer is not expecting the script to execute.

Not returning an error in this case does not help the programmer to have control of the situation. The programmer needs to have a realistic expectation of when the script will run (usually immediately or in the next few seconds).

Therefore, the most useful response here is to return an error, because the script will not execute until the user decides to uncollapse the tab group, which is an unpredictable event.