Closed Bug 247323 Opened 20 years ago Closed 20 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: 20 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: