Closed Bug 1454344 Opened Last year Closed Last year

Setting New tabs to |Blank Page| does not become effective until the 2nd new tab

Categories

(Firefox :: New Tab Page, defect, P2)

61 Branch
x86_64
All
defect

Tracking

()

RESOLVED FIXED
Firefox 61
Iteration:
61.4 - May 7
Tracking Status
firefox-esr52 --- unaffected
firefox59 --- unaffected
firefox60 --- unaffected
firefox61 --- fixed

People

(Reporter: alice0775, Assigned: Mardak)

References

Details

Attachments

(1 file)

STR
1. Open about:preferences > Home
2. Set New tabs to |Blank Page|
3. Click [+] button in tab strip

Actual Results:
Default page(i.e., top site etc..) is displayed

Expected Results:
Blank page
Severity: minor → normal
OS: Windows 10 → All
See Also: → 1415492
Summary: Set New tabs to |Blank Page| does not become effective → Setting New tabs to |Blank Page| does not become effective until the 2nd new tab
Iteration: --- → 61.4 - May 7
Priority: -- → P2
Probably just need to call removePreloadedBrowser from somewhere.. for every window. The preferences code is in content, so it would need to message. Could watch for a specific pref change from each browser window? Or I suppose activity stream could watch for pref change and iterate over windows.

k88hudson, any suggestions?
Flags: needinfo?(khudson)
I'd probably go with the approach of listening to the pref change in Activity Stream code and iterating over windows, yeah. I remember this causing weird test failures when we tried to do this before, but I'm not sure.

Does this happen with enabling an web extension that overrides new tab as well?
Flags: needinfo?(khudson)
(In reply to Kate Hudson :k88hudson from comment #2)
> Does this happen with enabling an web extension that overrides new tab as
> well?
Looks like no. Not sure if there's special code already to update the preloaded browser. Although this gets me thinking maybe we should react to changes from aboutNewTabService instead of activity stream code.
Assignee: nobody → edilee
Oh, turns out when an extension overrides, a new tab is used and not the preloaded one
Comment on attachment 8970754 [details]
Bug 1454344 - Setting New tabs to |Blank Page| does not become effective until the 2nd new tab.

https://reviewboard.mozilla.org/r/239500/#review245434

::: browser/components/preferences/in-content/tests/browser_newtab_menu.js:13
(Diff revision 2)
> +    menuItem.dispatchEvent(cmdEvent);
> +  }
> +
> +  const newtabMenu = doc.getElementById("newTabMode");
> +  const menuItems = newtabMenu.querySelectorAll("menuitem");
> +  ok(menuItems[0].selected, "The first item, Home (default), is selected.");

I don't suppose there's a way to select by id or something? Index seems a bit fragile
Attachment #8970754 - Flags: review?(khudson) → review+
Comment on attachment 8970754 [details]
Bug 1454344 - Setting New tabs to |Blank Page| does not become effective until the 2nd new tab.

https://reviewboard.mozilla.org/r/239500/#review245434

Clever!
Comment on attachment 8970754 [details]
Bug 1454344 - Setting New tabs to |Blank Page| does not become effective until the 2nd new tab.

https://reviewboard.mozilla.org/r/239500/#review245434

> I don't suppose there's a way to select by id or something? Index seems a bit fragile

I switched the list to
```js
const menuHome = doc.querySelector(`#newTabMode menuitem[value="0"]`);
const menuBlank = doc.querySelector(`#newTabMode menuitem[value="1"]`);
```
Pushed by edilee@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/733115bbb9b5
Setting New tabs to |Blank Page| does not become effective until the 2nd new tab. r=k88hudson
https://hg.mozilla.org/mozilla-central/rev/733115bbb9b5
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → Firefox 61
Component: Activity Streams: Newtab → New Tab Page
You need to log in before you can comment on or make changes to this bug.