Closed Bug 1025719 Opened 8 years ago Closed 7 years ago

openPreferences(panelName) doesn't open the requested pane if about:preferences is in a yet-to-be-loaded tab

Categories

(Firefox :: Preferences, defect, P2)

defect
Points:
5

Tracking

()

RESOLVED WORKSFORME
Iteration:
39.1 - 9 Mar

People

(Reporter: markh, Unassigned)

References

Details

Attachments

(1 file)

STR:
* Open about:preferences leaving it on the "general" tab.
* Switch to another tab.
* Exit Firefox
* Restart Firefox - note that about:preferences is now in a yet-to-be-loaded ("unloaded"?) background tab.
* Arrange for "openPreferences()" to be called - eg:
** Arrange for the "Choose what I share" telemetry infobar to appear and click the button
** Arrange for the sync error pane with the "Preferences" button to appear and click it
** Easier still - in a browser scratch-pad, execute:
 Services.wm.getMostRecentWindow("navigator:browser").openPreferences("paneSync")

Expected:
* Tab with about:preferences is made current and the "sync" pane is showed

Actual:
* Tab with about:preferences is made current, but "General" remains selected.  Browser scratchpad reports:

Exception: browser.contentWindow.selectCategory is not a function
switchToPane@chrome://browser/content/utilityOverlay.js:493:9
openPreferences@chrome://browser/content/utilityOverlay.js:507:7
@Scratchpad/1:13:1
WCA_evalWithDebugger@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webconsole.js:1065:7
WCA_onEvaluateJS@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webconsole.js:730:9
DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:1151:9
LocalDebuggerTransport.prototype.send/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/transport/transport.js:540:11
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:84:7

Note that it works fine if about:preferences is already fully loaded in either the selected or a non-selected tab.

cc jaws: Looks a little like bug 1020245, but that's marked as fixed and doesn't seem identical.
Attached patch PatchSplinter Review
The gotoPref call in utilityOverlay.js was obsolete now that the preference category is included in the URL hash.
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Attachment #8443272 - Flags: review?(ttaubert)
Comment on attachment 8443272 [details] [diff] [review]
Patch

Review of attachment 8443272 [details] [diff] [review]:
-----------------------------------------------------------------

AFAICT gotoPref() still exists, wouldn't it be better to use that? openPreferences() would simply need to handle pending tabs, probably in the same "advanced-pane-loaded" observer.
Attachment #8443272 - Flags: review?(ttaubert)
(In reply to Tim Taubert [:ttaubert] from comment #2)
> Comment on attachment 8443272 [details] [diff] [review]
> Patch
> 
> Review of attachment 8443272 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> AFAICT gotoPref() still exists, wouldn't it be better to use that?
> openPreferences() would simply need to handle pending tabs, probably in the
> same "advanced-pane-loaded" observer.

gotoPref still exists, but once the tab gets switched to it starts a race with the browser.loadURI code. If the browser.loadURI code kicks off first (which it seems to do in all of my testing), then the expected URL is overwritten by the restored URL from SessionStore.

The attached patch still has the same issue of gotoPref but now with switchToAdvancedSubPane.
Assignee: jaws → nobody
Status: ASSIGNED → NEW
Summary: openPreferences(panelName) doesn't open the requested pane if about:accounts is in a yet-to-be-loaded tab → openPreferences(panelName) doesn't open the requested pane if about:preferences is in a yet-to-be-loaded tab
Flags: firefox-backlog+
Points: --- → 5
Depends on: 1100223
Priority: -- → P2
This was fixed by bug 1100223.

I do still get:
Exception: TypeError: browser.contentWindow.gotoPref is not a function
openPreferences@chrome://browser/content/utilityOverlay.js:530:9
@Scratchpad/1:1:1

But everything seems to work fine.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Iteration: --- → 39.1 - 9 Mar
Flags: qe-verify+
There doesn't seem to be any more manual QA needed here since Mark confirmed this in comment 4. Setting as qe-verify+. Fell free to set it back if you think otherwise.
Flags: qe-verify+ → qe-verify-
You need to log in before you can comment on or make changes to this bug.