1578685 - When attempting to set 2 pages as homepage and only one of them is blocked, then the other should be correctly set as homepage

Status: NEW

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

Description

[Daniel Bodea [:danibodea]]

Note

• When attempting to set to webpages as homepage, but one of them is blocked by Remote Blocklisting feature, then the homepage preferences will be reset to default instead of levin the unblocked webpage as homepage.

Affected versions

• Nightly v71.0a1
• Beta v70.0b3

Affected platforms

• All

Steps to reproduce

1. Open browser.
2. Install the "remote-settings-devtools" extension on the browser.
3. Click the "Remote Settings Devtools" extension icon from the toolbar.
4. Change the Environment setting (from top-right corner) to Stage.
5. Click on "Clear ALL local data" button.
6. Click on the "Poll Server" button (or Click on the "Force Sync" button from the "main/hijack-blocklists" Collection.
7. In one tab open "https://www.google.com/" (currently unblocked page). Close the other tabs.
8. In a second tab open "https://www.ecosia.org/search?q=search+result+page" (currently blocked).
9. Open the browser's options page, Home tab.
10. Click on "Homepage and new windows" drop-down, and select "Custom URLs..." option.
11. Click the "Use current pages" button.

Expected result

• The unblocked webpage should be set as homepage, while the other should not.

Actual result

• None of the 2 webpages are being set as homepage.

Comment 1

[Jessilyn Davis]

Nan - is this related to the search hijacking work that UJet was working on this year? Did it just land in Beta?

Comment 2

[Nan Jiang [:nanj]]

I believe the Search team is actively working on the anti-hijacking feature now.

I wonder if this has to do with bug 1535049.

:standard8 - could you verify?

Comment 3

[Mark Banner (:standard8)]

Yes, this is a issue we didn't anticipate. I'm not sure it is super high priority as we don't expect users to be hitting this much as we'll be scoped to specific codes / parts of urls.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:thecount, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Jessilyn Davis]

Mark - does it make sense for these tickets (blocking Meta Bug 1578508) move to the Search component so you can triage in your usual work flow?

Comment 6

[Mark Banner (:standard8)]

(In reply to Jessilyn Davis from comment #5)

Mark - does it make sense for these tickets (blocking Meta Bug 1578508) move to the Search component so you can triage in your usual work flow?

I chatted with Mike de Boer, and we think that it is best to keep them in the New Tab page as that's where the actual functionality is affected. There shouldn't be too many more of these.

Longer term, I don't know who's going to be responsible for this part of the work.

Comment 7

[Jessilyn Davis]

Sounds good and thank you for the heads up on longer term.

Are you able to keep up with this work by having it block the Meta Bug 1578508 ok?

I just want to confirm that you've got what you need for visibility on these bugs and you aren't relying on the Pocket New Tab team to triage/work on these issues.

Thanks!

Comment 8

[Mark Banner (:standard8)]

(In reply to Jessilyn Davis from comment #7)

Are you able to keep up with this work by having it block the Meta Bug 1578508 ok?

Actually, this bug shouldn't block bug 1578508 as this isn't to do with extension preferences. This is just about how the homepage urls are blocked.

I think this isn't super high priority as a) I don't expect users to be generally setting these urls that match, b) I don't think they'll be setting multiples at the same time.

(I'll take the other question off-line).