Closed Bug 1317323 Opened 3 years ago Closed 3 months ago

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

Categories

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

52 Branch
defect

Tracking

(firefox69 verified)

VERIFIED FIXED
Tracking Status
firefox69 --- verified

People

(Reporter: leplatrem, Assigned: mtigley)

References

(Blocks 1 open bug)

Details

(Whiteboard: [dt-q])

Attachments

(1 file, 2 obsolete files)

- 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
Good find, thanks for the report!
Priority: -- → P3
In bug 1334249 comment 2, someone mentioned that both / and ' characters exhibit this behavior.
See Also: → 1334249
Duplicate of this bug: 1357406
Summary: Pressing / (slash) in a text input toggles "Quick find" → Pressing / (slash) or ' (quote) in a text input toggles "Quick find"
Duplicate of this bug: 1381583
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.
Duplicate of this bug: 1448289
Product: Firefox → DevTools
Duplicate of this bug: 1468945
Duplicate of this bug: 1494899
Duplicate of this bug: 1500127
Last comment is for FF62.

Can confirm, still happens in FF63.
Whiteboard: [dt-q]
Duplicate of this bug: 1505502
Blocks: rdm-ux

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...

Please fix this already...

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.

Assignee: nobody → mtigley
Status: NEW → ASSIGNED

(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.

(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.

Duplicate of this bug: 1529151

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.

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.

Flags: needinfo?(kmaglione+bmo)
See Also: → 1534925
Priority: P3 → P1
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.

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!

Attachment #9052729 - Attachment description: Part 1: Ignore the keyPress event in FindBarChild if in RDM. → Ignore the keyPress event in FindBarChild if in RDM.
Attachment #9052729 - Attachment description: Ignore the keyPress event in FindBarChild if in RDM. → Part 1: Ignore the keyPress event in FindBarChild if in RDM.
Whiteboard: [dt-q] → [rdm-mvp] [dt-q]
See Also: → 1322385

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.

Depends on: 1322385
Flags: needinfo?(kmaglione+bmo)

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

Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Attachment #9053954 - Attachment is obsolete: true
Attachment #9052729 - Attachment is obsolete: true
Whiteboard: [rdm-mvp] [dt-q] → [dt-q]

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

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.