Add in page search for websites

[mario]

Background

Multiple users have requested a feature to perform in page search in opened websites. Thus we'd like to provide this feature by allowing users to type search terms into the URL bar and then initiating in page search.

What to change

1. URL bar UI changes

Display a new "Find in page" list item at the top of the URL bar overlay as soon as a user starts to type in the URL bar as shown in this screenshot. For both - the list item headline and the list item - apply the ​default iOS table view style (as used for the search results but).

• Text for the new list item headline: Find in page (<n> matches) where <n> is replaced by the total amount of matches.
• Text for the new list item: Find "<string>" in page where <string> is replaced by the string the user has typed into the URL bar

Display the "Find in page" item described above only if all of the following criteria are met:

• The user has started to type any string into the URL bar
• The string in the URL bar is not empty
• A website is opened in the current tab

2. In page search

As soon as the new Find "<string>" in page item as described under 1. is tapped, perform the following actions:

• Close the URL bar menu and display the currently opened tab
• Keep the typed search term in the URL bar
• Close the keyboard
• Visually mark any instances of the specified search terms (the string in the URL bar) within the website as defined in this style guide ("HIGHLIGHT")
• If one or more occurrences of the specified search term was found, scroll to the first occurrence of the specified search terms beginning from the current scroll position
• Display the search bar as specified under 3.

3. Search bar

At the bottom of the website display a new element as defined in this style guide ("ACTION BAR", "MATCHES", "TOP RULE", "DONE BUTTON") and apply the following dynamic content within that element:

• Text of the "MATCHES" element: <n> of <m> matches where
  • <n> is replaced by the number of the currently selected occurrence of the search term and
  • <m> is replaced by the total number of occurrences of the search term.

Apply the following user interaction to the new search bar element:

• Tapping "Done" closes the search bar, removes any search term highlighting ("HIGHLIGHT") and removes the typed search term from the URL bar

Apply the following user interaction to the new search bar element only if one or more occurrences of the specified search term was found:

• Tapping the right arrow causes the website to scroll to the next occurrence of the specified search term and updates the numerical values of the "MATCHES" string as specified above.
  • Exception: If there is no next occurrence of the specified search term, the website scrolls to the first occurrence of the specified search term and updates the numerical values of the "MATCHES" string as specified above.
• Tapping the left arrow causes the website to scroll to the previous occurrence of the specified search term and updates the numerical values of the "MATCHES" string as specified above.
  • Exception: If there is no previous occurrence of the specified search term, the website scrolls to the last occurrence of the specified search term and updates the numerical values of the "MATCHES" string as specified above.

Technical limitation

Due to technical limitations and iOS-specific difficulties this issue does not aim to provide in page search options for child frames within the displayed website. This specific feature will be handled separately by the follow up issue #3930.

Attachments

The following attachments are linked within the description above:

• Style guide of the URL bar and search term highlighting
• Screenshot of the "Find in page" element in the URL bar
• Back arrow image (in the search bar)
• Next arrow image (in the search bar)

[pavelz]

The search activation method in Safari, which was an inspiration for search mode proposal per chapter 1, unfortunately has usability issues to it:

1. unscrollable suggestions. For the fulltext action to be still in sight, there is a space for at most 1-2 local histories and 2-3 search engine results - on iPhone6. On 5, it would be 1 local and 2 for search. The search engine is expected to give useful hints in first two suggestions.
2. insufficient feedback. User doesn't know if the phrase was found meaningfully, or even found at all.
3. no way to change the phrase after page is displayed. It only can be dismissed completely and searched again.

Safari somewhat improves issue 2 by displaying number of hits in the pagesearch "Section" header, which is still not good. Consider searching for "Impres" on a german page - the user doesn't know if the one hit is the omnipresent uninteresting "Impressum" or an actual content. Safari also mitigates option 3 by putting the phrase into the keyboard-attached search bar.

Possible solutions:

A) Safari way. Modify the current design per chapter above and live with restricted usefulness of search engine results

B) Chrome way. Fulltext reachable through separate menu option and typing happens in a dedicated text field with page visible. This models the desktop browser behaviors but is indeed uncomfortable on mobile device.

C) Stick with the undisputably comfortable direct typing to URL bar but do it differently:

C1) silently start searching right away even if user may not want to search. iPhone5+ is fast enough to do that. Do not mark matches in the page but display the total number of potential matches unobtrusively in the already present keyboard extension bar (next to punctuations and .com)

C2) upon clicking the match hint, activate full search mode. Mark matches, keep displaying the phrase in URL bar. Dismiss keyboard initially to maximize page sight. Show keyboard again if url bar is clicked. Dismiss search mode and display page URL again when Done is clicked.

I could actually imagine that the back/fwd arrows and abbreviated number of matches can be all placed in the URL bar. There is no need for saying "X of Y matches", simple "X/Y" is fine and does not need localization. The search term is generally very short and Cancel button is already there. In such case the extra utility bar in search mode is not needed at all.

[pavelz]

@mario 's email feedback

@Pavel, I can see your concerns about search results like "Impressum"/"Imprint" being hidden behind the "Find in page"-element. Wouldn't it be possible though to sort of make this element part of the bottom bar and not an overlay of the website view?

I admit this one unsolvable. There is generally two ways of approaching the UI: either the search mode is activated explicitly beforehand and then the text field can be placed elsewhere (Chrome way), or the URL bar is multifunctional and then it must continue fulfilling its primary function of URL bar overlay. Initially i thought that overloading the URL bar will improve user's comfort - no extra menu, automatic action. But this fact of hidden webpage (because the URL bar is still primarily a search bar) is making me think that extra menu is not THAT bad after all. User knows that he wants to search and he is fine with activating it somehow.

1.1. We currently display more that 2-3 history entries and search engine results in the "URL bar overlay". I'd also prefer to stick to that even though it requires the user to scroll down to reach the "Find 'xyz' in page" item.

That is generally the worst thing to do. You expect user to know where to find an app function which is not directly visible. Or needing to explain it, which is a sign of bad design.

[mario]

That is generally the worst thing to do. You expect user to know where to find an app function which is not directly visible. Or needing to explain it, which is a sign of bad design.

Chrome aside, it's where every other iOS user expects the feature to be as Safari handles it the same. I agree that it is not handled the best way - but opting for a different way of displaying the option might confuse even more users.

[mario]

I've adjusted the issue to reflect your proposed changes C1 and C2.

[pavelz]

So do you want follow Safari too in limiting the number of other search results? Displaying the page search after an unrestricted number of other search results (generally 1-2 local history + up to 10 websearch) will put it undoubtely beyond the first screen, therefore the hinting per C1 will be visible only if the user scrolls to it.

I would like to suggest a standalone search activation in the main menu. Everyone is used to it from the desktop browsers. The Safari way is not exactly an exhibit of a good UI worth following. Even if the immediate count is put elsewhere (keyboard extension bar) to not cripple the search results scrollability, the immediate visual feedback is obscured by the url bar overlay anyway ("Impressum" case)

The navigation bar design can be left as proposed.

[pavelz]

​https://www.pivotaltracker.com/story/show/118932427

[mario]

An issue was found with the current implementation of this feature:

1. Open ABB and go to any website, e.g. reddit.com
2. Initiate an in page search for "test" (the search bar appears)
3. Tap somewhere on the website to close the search bar

When closing the search bar by tapping somewhere on the website, the URL bar isn't cleared and "test" remains in the URL bar.
Compare this behaviour to closing the search bar by pressing "done" after repeating step 1. and 2. which clears the search bar and shows the original URL again.

[scheer]

The above-mentioned issue still occurs.

1. Open ABB and go to any website, e.g. reddit.com
2. Initiate an in-page search for "test" (the search bar appears)
3. Tap somewhere on the website to close the search bar

When closing the search bar by tapping somewhere on the website, the URL bar isn't cleared and "test" remains in the URL bar.

ABB 1.4.0 (988)
iPhone 6s Plus
iOS 9.3.1

[scheer]

Currently the above requirement states:

'If one or more occurrences of the specified search term were found, scroll to the first occurrence of the specified search terms'

I have found this not to be the case, however. In some instances, the user is presented with the 7th, or 2nd result before being shown results from 1 of <n>.

1. Visit reddit.com
2. Tap address bar and type 'h'
3. Select 'Find 'h' in page'

In this instance, there are 181 matches. But, instead of being loaded to result from 1 of 181, I am loaded to result from 7 of 181.

[pavelz]

​https://www.pivotaltracker.com/story/show/121069669

[scheer]

Scrolling through in-page search results on bbc.com causes the page to be moved off screen.

If the user, for example, searches for the letter 'f' and then begins to scroll through the highlighted results via the action bar, the whole page is either shifted partially to the left or completely off screen.

From what I can see, the further the search result to the right of the actual page is, the more the website shifts left and off the screen.

1. Open www.bbc.com
2. Select the URL bar
3. Enter 'F' and then select 'Find in page'
4. Scrolled the highlighted results with the '>' in the action bar

Observed results:
As the user moves through the selected results the webpage is moved to the left of the screen.

Intended behaviour:
The page should scroll down, displaying the highlighted results.

ABB 1.4.0-qa (1032)
iPhone 6s Plus
iOS 9.3.2

[pavelz]

@scheer there is something fishy about that particular "F" in bbc.com but i don't know what, yet. Some kind of CSS black magic edge case. Please confirm if this is happening to you:

1. Use Chrome/iOS. Load that page bbc.com. Invoke "Find in page" through right side menu.
2. Find "F". Go to LAST occurence (so that Chrome shows "50 of 50")
3. Observe that Chrome scrolls to the bottom of the page (correct)
4. Click Forward once (so that Chrome shows "1 of 50")
5. Observe that Chrome does NOT scroll to the top of the page (incorrect)

[pavelz]

Fixed in 1.4.0-qa build 1036

[pavelz]

Fixed in 1.4.0-qa build 1036

[scheer]

@pavelz I do indeed get the same issue with Chrome iOS. Scrolling past 58 (in this case it was 58/58) back to 1 does not then load me back to the top of the page, but rather one-third of the page up.

The issue is now resolved in ABB, however. Searching for 'f' on www.bbc.com and then cycling through the highlighted results scrolls through the page instead of moving the page to the left of the screen.

ABB 1.4.0-qa (1036)
iPhone 6s Plus
iOS 9.3.1

[Shikitita]

New issue found when doing Loc QA for the different new translations implemented:

1. Open Adblock Browser and access ​http://en.wikipedia.org
2. Make sure to have these languages keyboards enabled (Chinese (Simplified) - Pinyin, Chinese (Traditional) - Pinyin or Japanese - Kana)
3. Open Adblock Browser again and tap on the URL bar in order to perform an in-page search in wikipedia
4. Type for example "con" with any of the three keyboards mentioned before using the Latin alphabet that will be given as an option
5. Tap on the string displayed on the screen under the heading and which has the word being searched between quotation marks

6. After observing what happens, tap on "Done" at the bottom right of the screen

The screen will still display the in-page search strings while the website's URL can be seen at the top as well as the functions bar at the bottom. If tapping on the tabs icon at the bottom right, the screen will still display the in-page search strings.

[Shikitita]

Performing an in-page search with a Chinese Simplified keyboard

[Shikitita]

Attempting to open the tabs section after performing an in-page search with a Chinese Simplified keyboard

[pavelz]

Fixed in 1.4.0-qa build 1046
Retest with asian keyboard as well as latin: fulltext search suggestion appearance in autocomplete listing, behavior upon selecting the suggestion, behavior upon finishing the fulltext mode. The finishing button should be localized.