Status

()

enhancement
P1
normal
6 months ago
14 days ago

People

(Reporter: sdaswani, Assigned: andrei.a.lazar, Mentored)

Tracking

({meta})

Firefox 66
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(relnote-firefox 67+, firefox66 wontfix, firefox67+ fixed)

Details

User Story

1) User enables our search widget from Android Widget Menu.
2) The widget is a search box, a la Google's search widget that runs on Android.
3) When a user searches enters a search term into the box, a search with the user's preferred search engine is opened in Fennec.

Attachments

(3 attachments, 1 obsolete attachment)

Reporter

Description

6 months ago

I'm restricting this to Mozilla Internal until we figure out what we want to do.

Product would like us to create a simple 'search widget' for Fennec. See the user story.

Please note - we have had this already - see https://bugzilla.mozilla.org/show_bug.cgi?id=1221344#c5

The first part of this task is to 1) understand what we used to have and 2) describe how what we used to have is different than what is described above.

User Story: (updated)

We had a hard time keeping the user selected search engine in sync with the widget in the old version. I recall that Gecko would not flush the change to disk immediately and thus keeping the widget in sync was difficult.

Priority: -- → P1
Assignee

Updated

5 months ago
Assignee: nobody → andrei.a.lazar

If this poses problems, we could also add an option to the widget allowing users to select an engine that's different from the one set in the browser.

For reference: Chrome's approach is interesting, and could serve as a possible way forward here. When you focus on the Chrome search widget (the one that's installable via widgets), Chrome is immediately opened with the cursor placed in the address bar. This avoids keeping search engine preference in sync between widget and browser.

Assignee

Comment 4

5 months ago

Also from [https://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html#widgetCategory]:

"widgetCategory

Determines whether this widget can be displayed on the home screen, the keyguard, or both. A widget which is displayed on both needs to ensure that it follows the design guidelines for both widget classes [...]"

I think this is also a nice to have, what are your thoughts Andreas?

Flags: needinfo?(abovens)

Can we show a responsive UI quick enough to do the Chrome thing?

Why would we care about the keyguard widget when they are only usable on Android 4.x and lower. "The widgetCategory attribute declares whether your App Widget can be displayed on the home screen (home_screen), the lock screen (keyguard), or both. Only Android versions lower than 5.0 support lock-screen widgets. For Android 5.0 and higher, only home_screen is valid." https://developer.android.com/guide/topics/appwidgets/

Agree with Kevin. Just home_screen is enough.

Flags: needinfo?(abovens)
Assignee

Comment 7

5 months ago
Assignee

Comment 8

5 months ago

The build can be found here: https://drive.google.com/file/d/16MRFLInz5I1wv7rlwaQTPv1KevN9i4Lw/view?usp=sharing
The patch is still work in progress, with the UI being uncompleted as it serves a demo purpose for now.

In order to proceed further here:

  1. I need some UI indications in order to proceed further here, should I copy the design from the previous widget?
  2. Please review the functionality of the widget from the given demo.
Flags: needinfo?(abovens)

Comment 9

5 months ago

Andreas, I propose that we copy the design from the previous widget. Also can we have the search widget default to search in private mode? And if we do that does it hinder our ability to collect telemetry?

It would look dated. It was a pre-quantum design. It contained a couple problematic design elements most notably the new tab button. There were several issues resulting from incorrect Activity states (Android developer options -> Don't keep activities)

http://archive.mozilla.org/pub/mobile/nightly/2017/10/2017-10-01-10-03-34-mozilla-central-android-api-16-old-id/fennec-58.0a1.multi.android-arm.apk is a build that still has the widget and will install to org.mozilla.fennec.nightly and will not affect your Play Store Nightly build if you have one

I agree with Kevin. Copying the design from the previous widget doesn't make much sense as the new widget's functionality will be simplified, and the design should be modern. So, let's go for a design that is close to what Chrome ships, albeit visually aligned with Photon. Who from the graphics team could assist with this? Vesta, as this will go into Fenix eventually, is there a chance you can help finding a design resource?

We should also make sure that we collect telemetry on usage.

Also can we have the search widget default to search in private mode?

Why is that? I think users just want to do a normal search, not necessarily a private one.

Flags: needinfo?(abovens)
Flags: needinfo?(vzare)

Comment 12

5 months ago

After discussing this with product leads, the request is to just build a basic regular search widget (no private search).

I reviewed the functionality of the build that was posted. It looks good. It take a few seconds to launch (as it brings up the full browser, tries to load the last open tab, and then switches to search mode) and I was wondering if there was a way to make it faster. It seems like Chrome just launches a search view and not the full browser (bypasses the existing open tabs) so I am wondering if that's something we can consider?

In the meantime, I am working on finding a design resource.

https://docs.google.com/document/d/1Rk7e-3Tz1t0tYO33hQCGQ4goMt3BaSZnECDKcnsvgTM/edit

Flags: needinfo?(vzare)

Andreas, is that something we want to ship in 67 or is it planned for later? Thanks

Flags: needinfo?(abovens)

Comment 14

5 months ago

Andreas, I have secured a UX resource to work on this. Can we get this into 67?

Assignee

Comment 15

5 months ago

Vzare, I considered your suggestion and after investigating further, I concluded that we can't get a much better performance/experience on this feature without a significant amount of work and time.

The best experience improvement we can get at this point, with the lowest risk of regression would be to simply avoid restoring old tabs state and start with a fresh session. Anything else involves considerable more time and we would have to make sure we don't have anything more pressing in our backlog.

How should I proceed further?

Flags: needinfo?(vzare)

Comment 16

5 months ago

Thank you for investigating Andrei. I agree that we don't want to spend a significant time on this, and I like your proposed improvement of avoiding restoring old tabs an starting with the fresh session, I think that will make a huge performance improvement to the overall experience. I would like to proceed with that. How big is the effort and how long will it take?

Flags: needinfo?(vzare)
Reporter

Comment 17

5 months ago

Andrew what would happen to the old tabs state? Is it still recoverable if I launch Fennec later from the app launcher?

Flags: needinfo?(andrei.a.lazar)

Sorry for the delayed response.

I'm happy to aim for 67.

Is the initial delay also an issue when Firefox is open in the background, and a search is initiated through the widget? I'm a bit concerned about trashing the old tabs and starting with a fresh session, esp. if the old tabs state is lost.

Flags: needinfo?(abovens)
Assignee

Comment 19

5 months ago

Andreas and Susheel, regarding the old tabs state, let's take a look at the following scenario:

  1. I have some tabs open already (let's call this session X)
  2. I decide to open Fennec from the search widget
  3. Fennec will open with no old tabs state
  4. I continue my browsing, maybe generate even more tabs in this fresh new session (let's call this session Y)
  5. I decide to close Fennec
  6. Later, I decide to reopen Fennec from the app shortcut (normal app launch)

What should I see now?

case A: session X's tabs? (medium risk implementation)
case B: session Y's tabs? (the less error-prone implementation)
case C: a new session (let's call this session Z) which represents the merge between X's tabs and Y's tabs? (high risk of regression, a very complex and error-prone implementation)

Flags: needinfo?(sdaswani)
Flags: needinfo?(andrei.a.lazar)
Flags: needinfo?(abovens)

Comment 20

5 months ago

Andrei, I misunderstood when you suggested not restoring old tabs and opening a new session, I thought you were suggesting opening a new tab.

Using your test build, initiating a search by tapping the search box (1)opens the existing Fennec session, (2)tries to restore existing tabs first, (3)then brings up a new tab with the cursor in the URL bar and the keyboard invoked.

My ask was to remove step 2 only (restoring existing tabs) and going directly to a new tab without killing the existing tabs/session.

If that's not possible, then I think we shouldn't make any changes to the behaviour. Would love Andreas thoughts on this.

Reporter

Comment 21

5 months ago

I hate case B - it makes me not want to use the search widget, as it blasts my previous 'work'.

Is it possible to have a case D - put Fennec in 'Focus mode' - you can't open new tabs, i.e., there is only one tab based on your search; include a method to 'launch the app' from Focus mode, leading to session X + this new tab added.

This may be hard, just giving you my wish :) .

Flags: needinfo?(sdaswani)

Comment 22

5 months ago

When do you need the UX mock/specs in order to get this in 67 before code freeze on March 11?

Flags: needinfo?(andrei.a.lazar)
Assignee

Comment 23

5 months ago

(In reply to vzare from comment #22)

When do you need the UX mock/specs in order to get this in 67 before code freeze on March 11?

I think March 3 should be fine. Thank you for your prompt reply!

(In reply to :sdaswani only needinfo from comment #21)

I hate case B - it makes me not want to use the search widget, as it blasts my previous 'work'.

Is it possible to have a case D - put Fennec in 'Focus mode' - you can't open new tabs, i.e., there is only one tab based on your search; include a method to 'launch the app' from Focus mode, leading to session X + this new tab added.

This may be hard, just giving you my wish :) .

I agree with you, case B is not optimal indeed. On the other hand, case D seems more appropriate to what we want to obtain.
Let me investigate a bit further on this case and maybe I will come back with a build or, at least an answer by the end of the week.

I'm going to make a follow-up bug for this experiment. See https://bugzilla.mozilla.org/show_bug.cgi?id=1526887

Meanwhile, I'm waiting for your questions, concerns or any suggestion regarding Susheel's proposal.

Flags: needinfo?(andrei.a.lazar) → needinfo?(vzare)

When I do a search from the search widget, I simply expect the search to open in a new tab. If that's slower than expected, so be it. I don't want us to work around slow performance by trashing tabs or doing other complex stuff.

Flags: needinfo?(abovens)
Assignee

Updated

4 months ago
Summary: Search Widget for Fennec → [META] Search Widget for Fennec
Assignee

Updated

4 months ago
Depends on: 1526926, 1526929, 1526934

Comment 25

4 months ago

I agree with Andreas. My initial ask was to skip restoring existing tabs (not killing them) and going directly to a new tab. If that is not possible, then let's not change anything.

Flags: needinfo?(vzare)

Comment 26

4 months ago

Andrei, would you please provide a rough estimate on the engineering effort for the following 2 scope items based on these mocks (second page): https://docs.google.com/document/d/1Rk7e-3Tz1t0tYO33hQCGQ4goMt3BaSZnECDKcnsvgTM/edit

-Adding a homescreen widget (mockup is at the bottom of the screen)
-Adding a just in time prompt to help users discover this new feature

Flags: needinfo?(andrei.a.lazar)

The plan is to make Google the only option or is should it track Firefox's search settings?

Comment 28

4 months ago

The search widget should use the same search preferences as the browser.

Comment 29

4 months ago

Hi Andrei, can I have an estimate on the engineering work required based on the mocks shared above by Wednesday?

Assignee

Comment 30

4 months ago

Hello vzare, it would take roughly ~2 weeks, but I'm going to need all the specifications and assets from this invision - https://mozilla.invisionapp.com/share/UJQJP4IC7WN#/screens/347173313_Widget as soon as possible.

Flags: needinfo?(andrei.a.lazar) → needinfo?(vzare)

(In reply to Andreas Bovens [:abovens] from comment #18)

Sorry for the delayed response.

I'm happy to aim for 67.

Is the initial delay also an issue when Firefox is open in the background, and a search is initiated through the widget? I'm a bit concerned about trashing the old tabs and starting with a fresh session, esp. if the old tabs state is lost.

Hi Andreas and Vesta, are you still aiming 67? I am asking because the 67 beta cycle starts in 3 weeks.

Flags: needinfo?(abovens)
Assignee

Comment 32

4 months ago

Also the "Add automatically" option from the mock can't be implemented on versions lower than Android Oreo (API 26) [see https://developer.android.com/guide/topics/appwidgets/#Pinning]

Yes, we'd still like to aim for 67. As for the Oreo limitation, that is fine: we can restrict it to just that version. Users on older Android versions can just add it from the widgets drawer.

Flags: needinfo?(abovens)

Uplifting a feature with strings will cause some problems for the localization teams.

Comment 35

4 months ago

We can limit this feature to English locales only.

Flags: needinfo?(vzare)
Assignee

Updated

4 months ago
Depends on: 1531679
Assignee

Comment 36

4 months ago
Posted video v11.mp4
Attachment #9037527 - Attachment is obsolete: true
Assignee

Comment 37

4 months ago
Posted video v12.mp4
Assignee

Comment 38

4 months ago

Hello everyone, here you can find the new build.

What is different from the previous build:

  • Faster text/voice search action (now it should no longer wait for the previous tabs to load)
  • Improved design (still missing the final assets and the size configuration)
  • Handles the deep link (from Leanplum) which will generate an intent for adding the widget

I also created an experiment in Leanplum dashboard that demonstrates the feature discoverability through Leanplum.
It can be found under the name Search Widget – (Andrei) on "Firefox Android Dev" project.

Please check the functionality either by installing the APK or by watching the "Add automatically" and "Drag & Drop" videos.

Flags: needinfo?(vzare)

Comment 39

4 months ago

Thanks Andrei, I tested it and it looks good. And thank you for creating the LeanPlum experiment. Can we also add a Unique source value for the widget so we can record when user initiates search using the widget vs browser search bar?

Also here are the final UX mocks and specs: https://mozilla.invisionapp.com/share/UJQJP4IC7WN#/screens/349402550_Searchwidget

Let me know how you want the assets.

Flags: needinfo?(vzare) → needinfo?(andrei.a.lazar)
Assignee

Comment 40

4 months ago

(In reply to vzare from comment #39)

Thanks Andrei, I tested it and it looks good. And thank you for creating the LeanPlum experiment. Can we also add a Unique source value for the widget so we can record when user initiates search using the widget vs browser search bar?

Yes, I am currently working on this, the old event is "E_Interact_With_Search_URL_Area".
I am going to name the one triggered by the search widget "E_Interact_With_Search_Widget_URL_Area" for the moment.
Please let me know if the marketing team decides on a new name.

Also here are the final UX mocks and specs: https://mozilla.invisionapp.com/share/UJQJP4IC7WN#/screens/349402550_Searchwidget

Let me know how you want the assets.

The measurement specs (size, color, font etc.) from invision are enough, no need for extra stuff, thank you!

Flags: needinfo?(andrei.a.lazar) → needinfo?(vzare)
Depends on: 1532613
Depends on: 1532614
Depends on: 1532617
Depends on: 1532619
Depends on: 1532620

I've tested the functionality, and have filed a number of issues: see above.

Assignee

Comment 42

4 months ago

Hello everyone, this is the status for the tickets open by Andreas:

You can find here another build with the most recent changes and fixes.

Except the two WIP issues, do you feel like there are any other improvements to be made or blockers to be addressed before a PI request?

I am going to add Andrei Bodea from the QA team to this thread, so he can validate these issues on the latest build.

Flags: needinfo?(andrei.bodea)
Flags: needinfo?(abovens)

Comment 43

4 months ago

Andrei, thanks for the new build! It looks good and I can see that some bugs are fixed - but it's hard to test since the "add widget" prompt keeps popping up. Can we disable the prompt for users that have already added the search widget to their homescreen, and limit how often it pops up for other users?

Flags: needinfo?(vzare) → needinfo?(andrei.a.lazar)

(In reply to Andrei Lazar from comment #42)

You can find here another build with the most recent changes and fixes.

Hi Andrei,
I just installed this latest version. Overall this is such a HUGE improvement - thank you. I did see a few things that I think would be great to fix if we can:

  • The voice search action should just perform the search instead of making the user hit return. This would make it work like other voice search widgets.
  • When the widget is resized down to 3x1 the copy is truncated but the intention was to just make it say "Search" at this point.
  • When the widget is resized down to 2x1 there should be no copy at all. Currently it has ".."
  • Add the 1x1 widget size.
  • The widget install dialog doesn't have an accurate image of the widget (see attachment)
  • The font in use looks like Roboto Thin on my device. If it's actually "Regular" maybe we should try making it "Medium" to help with legibility.
Blocks: 1533361
Depends on: 1533611
Depends on: 1533634
Depends on: 1533645
Depends on: 1533646
Assignee

Comment 46

4 months ago

Hello everyone,
this is the overall status for this feature.

Status

Andreas

Andrei B.

Kevin

You can find here the latest build with the most recent changes and fixes.

What's different from the previous build

  • Widget's layouts are more responsive (1x1, 2x1, 3x1 and 5x1)
  • Added preview image for in-app prompt and widgets picker
  • Search widget intent no longer triggers "Tab queue prompt"

BIG NOTE

As per Android documentation due to a variety of sizes, densities and shapes, we can't know for sure what is/going to be the exact size of a 1x1, 2x1, 3x1 widget grid, but Android can guarantee us some "constraints" through the formula 70 × N − 30, where N is the number of cells.

number of cells minimum size (dpi)
1 40
2 110
3 180
... ...
N 70 × N − 30

Example

  • an S8 has a cell width = 66dpi
  • an S9 has a cell width = 80dpi

Conclusion

We can conclude that there may be devices where we'll never hit a specific configuration of widget (1x1 or 2x1 or 3x1).

Flags: needinfo?(andrei.a.lazar)
Assignee

Updated

4 months ago
Depends on: 1534205
Assignee

Updated

4 months ago
Depends on: 1533723
Assignee

Updated

4 months ago
Depends on: 1534207
Depends on: 1534413
Depends on: 1534488

n-i to myself to ask biz dev if there is any reason to keep this confidential. The code is in m-c at this point.

Flags: needinfo?(lhenry)
Flags: needinfo?(lhenry)

Discussed with mconnor, mcrandon. No reason to keep this hidden. We can also open up the dependent bugs.

Group: mozilla-employee-confidential
Depends on: 1534875

When will the remaining fixes land?

Flags: needinfo?(abovens)
Depends on: 1535028

Updated

3 months ago
Depends on: 1535030
Depends on: 1535045
Depends on: 1535418
Depends on: 1535616
No longer blocks: 1533361
Depends on: 1533361
Depends on: 1536003

Added to our 67 beta Release Notes with this wording:
A new Firefox Search widget can be added to the home screen from the Android Widget Menu

Type: defect → enhancement
Depends on: 1545116

For now I will clear my NI, as I was added to the bug so I can see it(as it was private) and validate the issues(done everything above).

Flags: needinfo?(andrei.bodea)

There is still one dependent bug linked to this bug, Bug 1535616. I guess when that is addressed we can close it out?

You need to log in before you can comment on or make changes to this bug.