Open
Bug 1255020
Opened 9 years ago
Updated 3 years ago
Location bar doesn't display caret and text selection if I click it after opening context menu of an item in downloads panel
Categories
(Core :: Widget: Win32, defect, P3)
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox47 | --- | wontfix |
firefox48 | --- | wontfix |
firefox49 | --- | wontfix |
firefox50 | --- | fix-optional |
People
(Reporter: arni2033, Unassigned)
References
Details
(Keywords: regression, Whiteboard: tpi:+)
>>> My Info: Win7_64, Nightly 48, 32bit, ID 20160308030418
STR:
0. Move downloads button to toolbar
1. Open http://example.org/ in active selected tab
2. Drag that tab to downloads button to download the page
3. Click downloads button to open downloads panel.
4. Rgiht-click the last item in that panel
5. Rgiht-click the last item in that panel
6. Click in urlbar
7. Type "a"
AR:
After Step 6 there's no text selection visible in urlbar
After Step 7 all text in urlbar is replaced with "a". There's no caret
Now text selection and caret are broken in the whole window.
ER:
After Step 6 the whole url in urlbar should be selected visually.
After Step 7 caret should be displayed after "a"
This is regression. Firefox 28 is unaffected, Firefox 31 is affected.
Updated•9 years ago
|
Component: Untriaged → Location Bar
As I said, "text selection and caret are broken in the whole window". Not only urlbar.
Component: Location Bar → Untriaged
![]() |
||
Comment 2•9 years ago
|
||
Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=10d56cf4ca6d&tochange=79595e16949f
Regressed by : 79595e16949f Masayuki Nakano — Bug 957019 Don't check mouse cursor position at handling non-mouse message in nsWindow::DealWithPopups() r=jimm+enndeakin
Blocks: 957019
Component: Untriaged → Widget: Win32
Flags: needinfo?(masayuki)
Keywords: regressionwindow-wanted
OS: Unspecified → Windows
Product: Firefox → Core
Version: Trunk → 29 Branch
Comment 3•9 years ago
|
||
Click download button:
> <000004> 00491CC0 P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:1558 yPos:68
> <000005> 00491CC0 P WM_LBUTTONUP fwKeys:0000 xPos:1558 yPos:68
Right click on the item:
> <000006> 00B71A1E S WM_MOUSEACTIVATE hwndTopLevel:00B71A1E nHittest:HTCLIENT uMsg:WM_RBUTTONDOWN
> <000007> 00B71A1E R WM_MOUSEACTIVATE fuActivate:MA_NOACTIVATE
> <000008> 00B71A1E P WM_RBUTTONDOWN fwKeys:MK_RBUTTON xPos:219 yPos:41
> <000009> 00B71A1E P WM_RBUTTONUP fwKeys:0000 xPos:219 yPos:41
Right click on the same item again:
> <000010> 00B71A1E S WM_MOUSEACTIVATE hwndTopLevel:00B71A1E nHittest:HTCLIENT uMsg:WM_RBUTTONDOWN
> <000011> 00B71A1E R WM_MOUSEACTIVATE fuActivate:MA_ACTIVATE
> <000012> 00B71A1E P WM_RBUTTONDOWN fwKeys:MK_RBUTTON xPos:161 yPos:47
> <000013> 00B71A1E P WM_RBUTTONUP fwKeys:0000 xPos:161 yPos:47
Left Click in the URL bar.
> <000014> 00491CC0 S WM_MOUSEACTIVATE hwndTopLevel:00491CC0 nHittest:HTCLIENT uMsg:WM_LBUTTONDOWN
> <000015> 00491CC0 R WM_MOUSEACTIVATE fuActivate:MA_ACTIVATE
> <000016> 00491CC0 P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:1070 yPos:70
> <000017> 00491CC0 P WM_LBUTTONUP fwKeys:0000 xPos:1070 yPos:70
Flags: needinfo?(masayuki)
Comment 4•9 years ago
|
||
Okay, I understand why you duplicated same step at #4 and #5.
If you omit step #5, clicking in URL bar causes closing only the context menu, i.e., doesn't cause closing the download panel. I think that this is expected popup behavior of Gecko.
However, otherwise, clicking in URL bar (clicking outside of the download panel) causes closing all popups. This bug causes hitting the hack to the hack of bug 957019 (http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp?rev=6fa89bbe833b&mark=7509-7515#7496).
(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #4)
> Okay, I understand why you duplicated same step at #4 and #5.
>
> If you omit step #5, clicking in URL bar causes closing only the context
> menu, i.e., doesn't cause closing the download panel. I think that this is
> expected popup behavior of Gecko.
Well actually when I first encountered this bug, I right-clicked one download item. It appeared disabled, because I already deleted/moved the file. So I right-clicked another download item, and it was also deleted/moved. Then I just clicked in urlbar.
What for the issue you described - I already filed bug 1171394 about it (probably more bugs, because that so called "expected" behavior causes many breakages)
![]() |
||
Comment 6•9 years ago
|
||
dolske, can we get a priority on this?
status-firefox47:
--- → wontfix
status-firefox49:
--- → affected
status-firefox50:
--- → affected
Flags: needinfo?(dolske)
Updated•9 years ago
|
Flags: needinfo?(dolske)
Updated•9 years ago
|
Whiteboard: tpi:?
![]() |
||
Updated•9 years ago
|
Priority: -- → P3
Whiteboard: tpi:? → tpi:+
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•