Closed Bug 247323 Opened 21 years ago Closed 21 years ago

<iframe src="javascript:1"/> partially hoses Mozilla

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: efk-mbug, Assigned: aaronlev)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: access, fixed-aviary1.0, fixed1.7)

Attachments

(2 files, 2 obsolete files)

Teensy weensy testcase: file only says <iframe src="javascript:1"/>
30 bytes, text/html
Details
Bandaid on a bandaid on a bandaid. A real fix for bug 93105 would be preferable.
898 bytes, patch
dbaron
: review+
bryner
: superreview+
asa
: approval-aviary+
asa
: approval1.7.5+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040608 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040608 Keyboard works fine until I opened http://oddpost.com in a new tab. After closing that tab, keyboard stops responding (space to go down a page, arrows, etc). Reproducible: Always Steps to Reproduce: 1. Got to a page that is longer then one screen full 2. Verify that keyboard scrolling works 3. Visit http://oddpost.com in a new tab 4. Close that tab 5. Attempt to use keyboard to scroll Actual Results: Scrolling doesn't happen Expected Results: Scrolling SHOULD happen Default theme.
I reduced html to the following offending snippet: ------------------------------------------------------- <script language="JavaScript"> var uniqueUrl = ( new Date() ).getTime(); document.write( '<iframe id="jsFrame" src="javascript:' + uniqueUrl + '" style="visibility:hidden; position:absolute; width:1px; height:1px;"></iframe>' ); </script> ------------------------------------------------------- This causes the bug on Mac and Win XP (same versions of Mozilla). I will try to change the bug to be both oses
Changed it to hardware:all and os:all. It has ONLY been tested on Mac os 10.2 and Windows XP.
OS: MacOS X → All
Hardware: Macintosh → All
Works for me using Firefox 0.8 on WinXP.
Same problem using Firefox 0.9 on Linux. Note that I can still type text in textboxes, so it doesn't freeze keyboard at all.
Confirmed that you can still type in textboxes. I can also get arrow control back some times, but not consistantly (by right clicking and left clicking repeatedly)
I see this w/ LInux 2004080905 using URL.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is quite a nasty bug. Notice that the reporter narrowed down the offending js in comment #1. Nice detective work.
Blocks: focusnav
Priority: -- → P1
Keywords: access, sec508
Attached file Very minimal testcase (obsolete) —
Slightly smaller version than in comment #1: <html><script> document.write('<iframe src="javascript:' + (new Date()).getTime() + '" ></iframe>'); </script></html>
Sometimes clicking in content restores scrollability, so it seems to be a focus issue. However if I use a bugzilla page as the scrollable page, then I have to click in a form control and then in content to get scrolling to work again.
Hmm, and then other times clickin in content doesn't help at all.
Seems to fail more consistently if I put a bookmark to the file in my bookmarks toolbar. Clicking in content restores focus after waiting about 15 or so seconds after you loaded the page. All kinds of other things broken, many things not: - Arrowing in this textarea is broken, but backspace and regular typing are working. Mouse works. - Attaching a file in bugzilla not working, keeps saying "You did not specify a file to attach" - Mozilla won't remember that I'm logged into bugzilla, keeps reasking for login
Attachment #159849 - Attachment is obsolete: true
Another hint, when in this mode, typing ' in a textarea triggers the find toolbar.
Summary: keyboard stops working (and cursor disappears) after visiting oddpost.com → <iframe src="javascript:1"/> partially hoses Mozilla
Flags: blocking-aviary1.0?
It's not a focus issue, it's a scrollview issue. If you click on another tab somehow it's document gets the same scrollview as the iframe document.
No, it's not a view problem. The normally-scrollable doc is trying to use the same presshell/selectioncontroller for its commands as the doc with the iframe.
Aha, tabbrowser.xml is calling setFocus() on the same window for both tabs.
Seems like the focus controller (attached by nsWindowRoot) isn't getting to hear the focus event for the window switch, thus it can't update it's concept of the current window. Maybe it's not hearing the event because the dead <iframe> can't pass it upwards.
Focus is suppressed because the page is still loading (via ::SetSuppressFocus). http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsPresShell.cpp#4669 However, the same number of unsuppressional calls needs to be made here, and aren't: http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsPresShell.cpp#4700 When focus is suppressed for the currently loading page, then the focus controller cannot focus another window when another tab is clicked.
A real fix for bug 93105 would be preferable. Although that fix went in before tabbed browsing, it still shouldn't leave focus suppression stuck on. Questions: - Where is a good place in the code that we can assert that focus suppression is off? - Why is focus suppression needed? Does it really need to suppress focus for windows when a new tab is being activated? Someone who knows nsIFocusController should help document the interface.
Attachment #159900 - Attachment is obsolete: true
Attachment #159975 - Flags: superreview?(bryner)
Attachment #159975 - Flags: review?(dbaron)
Comment on attachment 159975 [details] [diff] [review] Bandaid on a bandaid on a bandaid. A real fix for bug 93105 would be preferable. Yeah, we don't want to leave an extra focus suppression hanging around. The reason focus is suppressed is so we will ignore OS-generated focus events that occur during page load. For example, destroying the native widgets for the old page may generate blurs that we don't want, and creating new widgets may generate focus events that we don't want.
Attachment #159975 - Flags: superreview?(bryner) → superreview+
Comment on attachment 159975 [details] [diff] [review] Bandaid on a bandaid on a bandaid. A real fix for bug 93105 would be preferable. r=dbaron, although I'm mainly trusting you and bryner here since I don't know much about focus
Attachment #159975 - Flags: review?(dbaron) → review+
Attachment #159975 - Flags: approval-aviary?
Enter passphrase for key '/home/aleventhal/.ssh/id_dsa': Checking in nsPresShell.cpp; /cvsroot/mozilla/layout/html/base/src/nsPresShell.cpp,v <-- nsPresShell.cpp new revision: 3.778; previous revision: 3.777 done
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment on attachment 159975 [details] [diff] [review] Bandaid on a bandaid on a bandaid. A real fix for bug 93105 would be preferable. a=asa for branches landing. This needs to land on both aviary and 1.7.
Attachment #159975 - Flags: approval1.7.x+
Attachment #159975 - Flags: approval-aviary?
Attachment #159975 - Flags: approval-aviary+
Fixed on aviary and 1.7 branches
Flags: blocking-aviary1.0?
Keywords: fixed-aviary1.0, fixed1.7
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: