showing the native win32 print dialogue causes backward typing in other windows

NEW
Unassigned

Status

()

Core
Widget: Win32
P2
normal
10 years ago
6 years ago

People

(Reporter: shaver, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
x86
Windows NT
Points:
---
Bug Flags:
blocking1.9 -
wanted1.9.0.x +

Firefox Tracking Flags

(Not tracked)

Details

Forking this from bug 435917 to handle the Windows case.  Including the blocking1.9? here, but I think this is probably 3.0.1 fodder (easy workaround).

+++ This bug was initially created as a clone of Bug #435917 +++

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a1pre) Gecko/2008052702 Minefield/3.1a1pre

Steps to reproduce:
0) Open 2 windows and load a web page in each
1) In window 1's URL bar, type "javascript:window.print()" and load the URL. The native gtk print dialogue shows as modal to window 1.
2) In window 2's URL bar, type "www.gnome.org"

Results:
You actually typed "gro.emong.www" in window 2's URL bar!

Same happens if you type in form controls in window 2's web page, if the web page is from a different host than the one in window 1.

Similar to bug 179307, and marking security sensitive b/c of bug 179307 comment 14. That bug also shows how to fix the problem.

The gtk native file chooser dialogue code has the same problem, but I couldn't find a way to show this behaviour since there's no way to pop it up from page JS.
Flags: blocking1.9?
Summary: showing the native gtk+ print dialogue causes backward typing in other windows → showing the native win32 print dialogue causes backward typing in other windows
(WTF do you pick to say "all windows platforms"?)

Can the file dialogue be triggered from content by forcing an event onto a file upload, maybe just focus?
OS: Linux → Windows NT
Not blocking, see you in 3.0.1!
Flags: wanted1.9.0.x?
Flags: blocking1.9?
Flags: blocking1.9-
Yeah, wanted 1.9.0.x, it's probably a similar fix to the linux case.
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Priority: -- → P2

Updated

9 years ago
Duplicate of this bug: 439606
I don't see how this is an exploitable security problem that needs to be hidden. What am I missing?
Whiteboard: [sg:investigate]

Comment 6

9 years ago
Comment 0 says this is security-sensitive because of bug 179307 comment 14.
Group: core-security
Whiteboard: [sg:investigate]
You need to log in before you can comment on or make changes to this bug.