1317323 - Pressing / (slash) or ' (quote) in a text input toggles "Quick find"

Status: VERIFIED FIXED

(DevTools :: Responsive Design Mode, defect, P1)

Description

[Mathieu Leplatre [:leplatrem]]

- Version 52.0a1 (2016-11-13) (64-bit)
- Go to some form with text input (eg. https://jsfiddle.net/90jev19x/)
- Type some slashes: works fine.
- Toggle Responsive Mode
- Type some slash character by character like a URL: no way since it toggles quick find

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Good find, thanks for the report!

Comment 2

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

In bug 1334249 comment 2, someone mentioned that both / and ' characters exhibit this behavior.

Comment 5

[lijoyem]

User Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0

On responsive mode, text input is not responding to keyboard entries. I made sure I clicked on the input text, still the same issue. When I type it just start a search on the page. 

Even on this input, it happens.

Comment 10

[Leho Kraav (:macmaN @lkraav)]

Last comment is for FF62.

Can confirm, still happens in FF63.

Comment 12

[Pete Ford]

This is still present in FF63.0 on Ubuntu: slash character works in normal display but in responsive mode (in my case iPhone 6/7/8 size) I get the quick find box when I type / in an input field.
I can paste / from clipboard as a work-around...

Comment 13

[gumbeto]

Please fix this already...

Comment 14

[Micah [:mtigley] (she/her)]

It looks like this might have something to do with tunneling between the inner and outer browser. Pressing / or ' still causes the browser's shouldFastFind (https://searchfox.org/mozilla-central/source/toolkit/modules/BrowserUtils.jsm#294) event handler to return true since the target is the iframe mozbrowser rather than the text input element.

I'll continue investigating this issue.

Comment 15

[Patrick Brosset <:pbro>]

(In reply to gumbeto from comment #13)

Please fix this already...

Simply asking for a problem to be fixed isn't going to make anything better.
As you can read on the Bugzilla Etiquette:

"Open Source" is not the same as "the developers must do my bidding." Everyone here wants to help, but no one else has any obligation to fix the bugs you want fixed. Therefore, you should not act as if you expect someone to fix a bug by a particular date or release. Aggressive or repeated demands will not be received well and will almost certainly diminish the impact of and interest in your suggestions.

Comment 16

[gumbeto]

(In reply to Patrick Brosset <:pbro> from comment #15)

I am sorry if I sounded aggressive or unkind, I did not mean it that way. I meant to request, not demand. But I also wanted to emphasize time passing and convey user frustration. These may be relevant factors to judge a bug (user experience is presumably taken into account in some form). That does not mean there is an obligation involved. The developers may even decide they "won't fix". But it would be kind to inform users of that decision (which ultimately may influence theirs).

Simply asking for a problem to be fixed isn't going to make anything better.

I beg to differ. Requests signal something useful, unless you attribute no weight at all to user satisfaction. Although admittedly I question whether that is a valid assumption with Mozilla lately. Requests may also serve as reminders when there is no clear answer after a long time.

I don't understand why requests bother you so, even if "repeated" by differen users. Let me remind you that Mozilla makes requests all the time (for donations, usage data, set as default browser, subscribe to news feeds, etc.). And of course many of these requests are "repeated" by multiple companies. I don't think that should be seen as bad practice at all.

In the end this just looked like it had slipped under the rug and sometimes "simply asking" may cause a forgotten bug to be remembered.

Comment 18

[Teresa]

anxiously waiting to get this bug fixed too. Could this be a mapping issue. In our keyboarding program when you press ' the quick search comes up and then have to click in text field again to get focus back.

Comment 19

[Micah [:mtigley] (she/her)]

Attachment: modify_FindBarChild_actor.patch

This patch handles showing the findbar in RDM from the FindBarChild actor. It fixes the issue of unexpectedly opening the findbar when a text input element is focused while in RDM, but it also handles the case where if FAYT is disabled we still need to initialize the findbar in case the user decides they want to trigger it by pressing / or '.

Kris, I have needinfo'd you for your input on this.

Comment 20

[Kris Maglione [:kmag]]

Comment on attachment 9051370 [details] [diff] [review]
modify_FindBarChild_actor.patch

Review of attachment 9051370 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/actors/FindBarChild.jsm
@@ +59,5 @@
> +    // Disable FAYT if the current window is in Responsive Design Mode. We know this is
> +    // the case if the getViewportBrowser is available on the Window object as this method
> +    // is added and used by RDM to access the viewport browser when touch simulation is
> +    // enabled.
> +    if (this.content.getViewportBrowser) {

I'd really rather we check the document URI.

@@ +65,5 @@
> +      // Findbar.
> +      let key = String.fromCharCode(event.charCode);
> +      if ((key == "/" || key == "'") && FindBarChild.manualFAYT &&
> +          !this.content.gBrowser.isFindBarInitialized()) {
> +        await this.content.gBrowser.getFindBar();

I'm not sure what the purpose of the `await` is?

I'm also not sure why why we need to call `getFindBar` here.

Comment 21

[Micah [:mtigley] (she/her)]

I'm not sure what the purpose of the await is?

I'm also not sure why why we need to call getFindBar here.

I realized we can handle the FindBar initialization from the RDM devtools side, so those last parts can be discarded. Thanks!

Comment 22

[Micah [:mtigley] (she/her)]

Attachment: Part 1: Ignore the keyPress event in FindBarChild if in RDM.

Comment 23

[Micah [:mtigley] (she/her)]

Attachment: Part 2: Handle keypress events specifically for the findbar in RDM

Comment 24

[Brad Werth [:bradwerth]]

I think there is a deeper issue here that's covered by Bug 1322385. The proposed patches may solve the narrow issue for this bug, but I worry that they may be unneeded once Bug 1322385 lands. For now I'm marking it as a blocker, but this bug may ultimately be closed as a duplicate of Bug 1322385.

Comment 25

[Micah [:mtigley] (she/her)]

Resolving this since work from Bug 1322385 has fixed the issue.

Comment 26

[Rares Doghi, Desktop QA]

This issue is Verified as Fixed in Nightly 69.0a1 (2019-06-03).