1442782 - Search field in bn.com only refreshes page when using keyboard enter

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Surferdude84]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532

Steps to reproduce:

Problem only appears on Mozilla Firefox Android
1. Go to http://www.bn.com
2. Click the search button.
3. Enter something into the search field. (Notice there is no search button to start search).
4. Click Enter on your mobile keyboard to begin search.
5. Website redirects back to original page and does not go to the search result page.

I have tried different keyboards including Samsung Keyboard and Swift Keyboard and the problem still exists.

The problem does not exist on Chrome for Android, Samsung Internet, and even Mozilla Focus.


Actual results:

Hitting enter on the mobile keyboard in the search field for http://www.bn.com will cause the page to refresh and not redirect to the Search Result Page.


Expected results:

After hitting enter on the search field for http://www.bn.com. The page should redirect the the search results page.

Comment 1

[Jan Henning [:JanH]]

Can be reproduced on desktop Firefox as well when visiting https://m.barnesandnoble.com/

Comment 2

[Mike Taylor [:miketaylr]]

Dennis, this doesn't look like fallout from Bug 1443117, but could you dig in here?

Comment 3

[Dennis Schubert [:denschub]]

Attachment: Simple testcase illustrating the issue (hit return inside the input field)

It is indeed not related to bug 1443117, but boils down to a simple timing issue, unfortunately.

The form containing the input is a simple `<form action="">` which explains the behavior of getting back to the index page on submit. They do not have a handler for `submit` on the form to catch the enter key and prevent the form from being submitted. Instead, they added a `keyup` handler to the input element. That handler can be found in [0] when searching for `$(".sk_mobContentSearchInput").keyup`.

The entire keyboard event handling is done inside a setTimeout function with a delay of 100ms, probably to throttle the autocomplete calls. When the key pressed was the enter key, they end up calling `navigateToSearchPage`, which in turn calls `skMobileTemplate.gotoPage`, and that ultimately sets `window.location` to the search results page.

Now, here is the thing: as mentioned, everything, including the change of `window.location` happens after 100ms timeout, after which we are already gone. We submit the form, and that's it. The code never gets a chance to change the location.

I attached a simple test case. In Firefox, it *usually* just submits the form, while in Chrome, it *usually* ends up loading this bug. Note that I said *usually*, because I experienced both cases reversed, although that was rare. If you put the HTML file on a particularly slow server, for example, we also load the new `window.location` eventually.

I don't think there is anything we can do here on our side, quite honestly. They depend on the window location being updated faster than the form is getting submitted, and that's not a good thing. The cleanest solution would be to attach an onsubmit handler to the form, and preventing the form submission there. There is no reason to ever submit that <form>, so they could also just add an "empty" handler to that, just preventing the form submission, and keeping the other code parts for input handling exactly as is.

Adam, could you do some outreach here? :)

[0]: https://m.barnesandnoble.com/skavastream/studio/loadJSModules?campaignid=772&env=prod&reshash=a2c93ce23a375a62a115343392b55300&custom=6_ev,7_ev,8_ev,9_ev,10_ev,11_ev,12_ev&pageid=6&view=bnbresponsive&publishid=638385&skcExViewPreviewId=24&evPublishId=24

Comment 4

[Dennis Schubert [:denschub]]

> I attached a simple test case.

Please note that my test case is a bit... wrong for hosting on bugzilla. When submitting the form, it tries to load `https://bug1442782.bmoattachments.org/attachment.cgi` with invalid GET parameters, which then redirects to this bug, so it looks exactly like in Chrome unless you look at the DevTools Network tab. It's probably best to download the test case to a local machine or test it at https://stuff.schub.io/mozilla/testcases/bz-1442782/ - sorry for that.

Comment 5

[Adam Stevenson [:adamopenweb]]

Apologies for the delay here. Reaching out to the Director of Web Services at Barnes & Noble via LinkedIn.

Comment 6

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 7

[Raul Bucata]

The issue has been fixed, as I was not able to reproduce the issue. The search function works as expected, as I was able to use the search field/search button to perform a search query, which returned valid results after pressing the "Enter" key on the keyboard of my test devices:

https://prnt.sc/JODq433P3ySv

Reporter, could you please confirm this?

Tested with:

Browser / Version: Firefox Nightly 100.0a1 (2015870571 -🦎100.0a1-20220323094932🦎)
Operating System: Samsung A51 (Android 11) -1080 × 2400 pixels 20:9 aspect ratio (~405 ppi density)
Operating System: Google Pixel 3 (Android 12) -1080 x 2160 pixels, 18:9 ratio (~443 ppi density)