'Choose Download Folder' window is displayed again after changing the download folder and navigating to a different page using enter in the location bar (enter keypress leaks to content from the location bar)
Categories
(Firefox :: Address Bar, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox67 | --- | unaffected |
firefox68 | --- | verified |
firefox69 | --- | verified |
People
(Reporter: arus, Assigned: dao)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [iris])
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details |
Steps to reproduce:
- Launch Firefox with a new profile.
- Navigate to about: preferences.
- Type 'downloads' in 'Find in Options'.
- Make sure 'Save files to' is checked.
- Click on 'Browse...'
- Click on 'New folder'.
- Type the name for the new folder and hit Enter.
- Tap on 'Select folder'.
- From the same window tab, Navigate to 'https://www.thinkbroadband.com/download' page.
Expected results:
https://www.thinkbroadband.com/download page is loaded.
Actual results:
'Choose Download Folder' window is displayed again with https://www.thinkbroadband.com/download page loaded in the background.
Notes:
- Please note that this is reproducible only when you navigate inside the same tab you've done the changes on downloads folder.
Comment 1•6 years ago
|
||
Hi Alin,
I assume there's a missing step here, where you have to initiate a download from the https://www.thinkbroadband.com/download page to get the download dialog to appear. Is that correct?
Hi Mike,
You don't have to download some files before, just make sure that after changing the downloads folder, you navigate inside the same tab to a different site, doesn't matter if is https://www.thinkbroadband.com/download .
Comment 3•5 years ago
|
||
I reproduced on Windows in beta. The 'enter' keypress in the location bar when trying to navigate somehow also makes it way to the preferences content in the page and activates the "browse" button again.
(Note: in future, please be specific about how you navigate to a page... if you use a bookmark or your mouse, I don't think this will reproduce)
Alin, how confident are you that this doesn't reproduce on 67? Can you find a regression window?
Hi guys,
Using Mozregression, I've got this:
2019-06-04T16:36:35: INFO : Narrowed inbound regression window from [38a326f8, a8fcad58] (6 builds) to [d1f9cf74, a8fcad58] (2 builds) (~1 steps left)
2019-06-04T16:36:35: DEBUG : Starting merge handling...
2019-06-04T16:36:35: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=a8fcad5870bad1bc7d9b355e2b3348753f7385c7&full=1
2019-06-04T16:36:36: DEBUG : Found commit message:
Bug 1548031 - Enable the QuantumBar on Nightly and early Beta. r=adw
Differential Revision: https://phabricator.services.mozilla.com/D29538
2019-06-04T16:36:36: DEBUG : Did not find a branch, checking all integration branches
2019-06-04T16:36:36: INFO : The bisection is done.
2019-06-04T16:36:36: INFO : Stopped
Comment 5•5 years ago
|
||
Alright, seems that the location bar used to swallow the 'enter' keypress and the quantumbar implementation doesn't do this. Hopefully that's easy to fix. Mike/Drew, can you help prio this? Thanks.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 6•5 years ago
|
||
I think this only reproduces with content running in the chrome process. There seem to be two factors to this, the first being whether we consume the key event (i.e. call preventDefault), the second being when we move focus to the content area. I don't see the legacy code consuming the event, so I suspect we move focus earlier. I don't see downsides to just always consuming the event, so I'm going to approach this bug this way.
Assignee | ||
Comment 7•5 years ago
|
||
Comment 9•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 10•5 years ago
|
||
Comment on attachment 9070774 [details]
Bug 1554158 - Always consume the enter key in UrlbarInput. r=Standard8
Beta/Release Uplift Approval Request
- User impact if declined: see comment 0 (only affects content loaded in the parent process, such as about:preferences)
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: see comment 0. (I want to look into writing an automated test but think we should uplift this in the meantime.)
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Always consuming the enter key event in the location bar should be fairly safe, I can't think of possible downsides... (famous last words.)
- String changes made/needed:
Comment 11•5 years ago
|
||
Comment on attachment 9070774 [details]
Bug 1554158 - Always consume the enter key in UrlbarInput. r=Standard8
fingers crossed, eh? approved for 68.0b10
Comment 12•5 years ago
|
||
bugherder uplift |
Updated•5 years ago
|
Comment 13•5 years ago
|
||
Verified - Fixed on latest Beta 68.0b10 (64-bit) and Nightly 69.0a1 (2019-06-12) on Windows 10 x64.
Updated•3 years ago
|
Description
•