get_page_content hangs forever when a page read never commits
Categories
(Core :: Machine Learning: On Device, defect, P1)
Tracking
()
People
(Reporter: thasan, Assigned: thasan)
References
(Blocks 1 open bug)
Details
(Whiteboard: [aiplatform])
Attachments
(2 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-beta+
|
Details | Review |
PageExtractorParent.getHeadlessExtractor loads a URL in a hidden browser and ends with:
return callback(await actorResolver.promise);
actorResolver (PageExtractorParent.sys.mjs:211) is only ever resolved from inside the onLocationChange listener, and nothing above it has a timeout — HiddenFrame.sys.mjs:216 withHiddenBrowser is a bare try/finally. Several paths leave the promise pending forever, which hangs the Smart Window turn with no error, no recovery, and no user-visible cause.
Updated•1 month ago
|
Updated•1 month ago
|
Comment 4•1 month ago
|
||
Verified as fixed in our latest Nightly 155.0a1 (2026-07-30)
Comment 5•1 month ago
|
||
I think this issue also occurs in Beta, im getting some large hang times when im searching through history, or when Im trying to get the content of a page.
Comment 6•1 month ago
|
||
The patch landed in nightly and beta is affected.
:thasan, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
- If no, please set
status-firefox154towontfix.
For more information, please visit BugBot documentation.
Original Revision: https://phabricator.services.mozilla.com/D314825
(cherry picked from commit 900a2c58924a65093f2eead579dace01f18bd357)
Updated•1 month ago
|
Comment 8•1 month ago
|
||
firefox-beta Uplift Approval Request
- User impact if declined/Reason for urgency: Smart Window's get_page_content hangs forever when a headless page read never commits, a stalled network response, or bot detection redirecting to a challenge page on another host. The turn stalls with no error, no recovery, and no user-visible cause.
- Code covered by automated testing?: yes
- Fix verified in Nightly?: yes
- Needs manual QE testing?: yes
- Steps to reproduce for manual QE testing: An example website, "tell me about ign.com go on the page" Ign.com should block headless extraction and the page should never load. In this case after 15s the headless extractor should return and show that it couldnt load the page.
- Risk associated with taking this patch: low
- Explanation of risk level: Adds a timeout around an await that previously had none, plus a rejection handler on an already-existing promise, governed by a new pref (browser.ml.pageExtractor.headlessTimeoutMs, default 15s). Behavior is unchanged whenever the load commits; the only new path is the failure path that previously hung forever. Scoped to the PageExtractor headless read.
- String changes made/needed?: None.
- Is Android affected?: no
Updated•1 month ago
|
Updated•1 month ago
|
Updated•1 month ago
|
Comment 10•1 month ago
|
||
| uplift | ||
Comment 11•1 month ago
|
||
Verified as fixed in our latest Beta 154.0b6
Description
•