All text input fields on window, including URL Bar, refuse input while a certain document is displayed

RESOLVED WORKSFORME

Status

()

--
major
RESOLVED WORKSFORME
15 years ago
13 years ago

People

(Reporter: novafyre01, Unassigned)

Tracking

({qawanted})

Trunk
PowerPC
Mac OS X
qawanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040406
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040406

The page at http://www.azsexoffender.com/ renders correctly, but input to the
fields in forms are disabled. Input to the address field at the top of the
browser window is also disabled. If input frame is re-rendered in a window of
its own, input is enabled for the form field and for the brower's address field.

Reproducible: Always
Steps to Reproduce:
1. click Search in the left frame
2. click Zip Code in the pop down that appears

Actual Results:  
input to the Enter Zip Code field is disabled as well as input in the address
field at the top of the window

Expected Results:  
should allow entry of data to the Enter Zip Code field

The page at http://www.azsexoffender.com/ does not pass validation. It uses
attributes reserved for frame elements in frameset elements.

Comment 1

15 years ago
WFM 20040406 PC/WinXP

Comment 2

15 years ago
Confirmed using Fizzilla-Mach/2004-03-16-13. While the URL is loaded, any text
input element anywhere else on the same window (including other tabs as well as
the Location Bar) also refuses input.

Also, the New Tab keyboard shortcut appears to stop functioning unless a new
window is spawned, at which time it resumes functionality (though text input
fields continue to refuse input).

Needs additional QA with minimized testcase generation if possible. Probably not
Parser; let's start with Event Handling.
Assignee: parser → events
Status: UNCONFIRMED → NEW
Component: HTML: Parser → Event Handling
Ever confirmed: true
Keywords: qawanted
QA Contact: ian
Summary: input is disabled although page with frames renders correctly → All text input fields on window, including URL Bar, refuse input while a certain document is displayed

Comment 3

15 years ago
PC, Win XP, ver 1.4, 1.6 (czech language pack)

Can not write anything to all types of input boxes. When value is assigned to a
input, pressing backspace won't erase last letter, but window.history.back() is
the result.
Seems to me like mozilla ignores, that I'm in input box and I want to write.
Instead of it all keys work like I'm outside of an input.

solution: Change the focus, minimize, reload the page

Comment 4

13 years ago
this worksforme with linux trunk 2005063005.
is this still a problem on Mac?

Comment 5

13 years ago
(In reply to comment #4)
> this worksforme with linux trunk 2005063005.
> is this still a problem on Mac?

Seems to worksforme with Mac OS X trunk 2005062810. In
http://www.azsexoffender.com/ I can enter text in the input fields/url bar,
provided that I click in the fields (to focus) before.

(Reporter)

Comment 6

13 years ago
Since I reported the problem, azsexoffender.com site redesigned its search
function. However, before the redesign, I recall checking a beta release that
fixed the problem. I haven't found any web sites that cause a similar problem as
of the 1.0.4 release. I suggest this issue be marked as fixed.

Comment 7

13 years ago
thanks, Mark

resolving WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.