Closed Bug 1383762 Opened 3 years ago Closed 3 years ago
Plum] Focus promotion triggered by unrelated actions
59 bytes, text/x-review-board-request
Device: HTC Nexus 9 (Android 7.1.1) Build: Nightly 56.0a1 (2017-07-24); Prerequisites: LeanPlum is turned on in Switchboard. Focus is not installed on the device. Steps to reproduce: 1. Open Fennec and a new tab. 2. Close and reopen Fennec. 3. On the last restored tab, tap the bookmark icon, or open the Custom menu>Settings. Expected result: The Focus promotion is displayed when a new tab is opened. But should not be displayed when you bookmark a page or open a menu. Actual result: Focus promotion is displayed when you bookmark a page or open a menu, after a restart.
Thanks Oana I guess when you do close Fennec, the Focus promotion dialog was visible? In that case, user haven't interact with the dialog and close the app directly, will see the last dialog again when he triggers another event again (Here are "App Start" and "Save Bookmark" , note: starting the setting page also consider as "App Start") I've added a way to prevent users to see the same prompt again in Leanplum backend. This should help fix above scenario and prevent the user from seeing the same dialog again.
Hi Nevin, I didn't have the Focus promotion dialog visible before closing the browser. In yesterday's testing session we modified the Focus promotion trigger to be once per every session, but the issue is still reproducing now that you've changed the trigger rules. For more details, I've recorded the issue and you can view it here: 1. Dialog opened by the Settings menu: https://goo.gl/ZE1c1K 2. Dialog triggered by bookmarking a page: https://goo.gl/wDpQ You can see that there is no new tab opened in the process. note: I've restarted the browser 4 times to get the other promos out of the way.
Comment on attachment 8889929 [details] Bug 1383762 - Change the event timing for adding a new normal tab. My previous patch for Bug 1383765 fixed a part of this issue . But this new patch can solve the problem once for all. It also fixed the issue that "Focus promotion triggered by unrelated actions". I shouldn't send the event under BrowserApp's onOptionsItemSelected directly otherwise the event will be triggered even when the user goes to setting page or bookmark list. Putting NEW_TAB event under Tabs's public addTab() method is better cause it's the unified entry when TabStrip or BrowserApp or TabsPanel wants to open a brand new tab.
Comment on attachment 8889929 [details] Bug 1383762 - Change the event timing for adding a new normal tab. https://reviewboard.mozilla.org/r/160986/#review166570
Attachment #8889929 - Flags: review?(max) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/0f58f3281582 Change the event timing for adding a new normal tab. r=maliu
This patch adjust current code flow. Should consider a minor fix so I landed during soft code freeze period. Hi Oana Please help verify on Nightly again once it's landed. Thanks!
Verified as fixed on Nightly 56.0a1 (2017-07-26). Device: LG Nexus 5 (Android 6.0.1)
You need to log in before you can comment on or make changes to this bug.