Closed Bug 236596 Opened 18 years ago Closed 17 years ago

form element cannot get focus when loaded by XML/XSLT page

Categories

(Core :: XSLT, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: jeffrey.g.lewis, Assigned: sicking)

References

()

Details

(Keywords: fixed-aviary1.0.1, fixed1.7.6)

Attachments

(14 files, 3 obsolete files)

20.00 KB, application/x-tar
Details
968 bytes, application/zip
Details
1.11 KB, application/zip
Details
1.29 KB, application/x-gzip
Details
89 bytes, text/xml
Details
445 bytes, text/xml
Details
2.06 KB, application/x-zip-compressed
Details
1.19 KB, text/html
Details
1.32 KB, application/x-gzip
Details
410 bytes, text/plain
Details
439 bytes, text/plain
Details
579 bytes, text/plain
Details
85 bytes, text/plain
Details
2.49 KB, patch
peterv
: review+
peterv
: superreview+
Details | Diff | Splinter Review
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040219
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040219

I have a window with two frames.  I click on a link in the left frame, causing
an XML page to be loaded into the right hand frame.  It gets turned into HTML
using XSLT.  There is a form in the resulting right hand page.  I click on a
text <input> element and try to enter text, but apparently the left hand frame
still has focus.  I get "link not found" errors in the status bar unless I type
letters in the link text in the left frame.
Sometime by selecting another window and then returning to the Mozilla window I
can get the focus to the <input> element.

Reproducible: Always
Steps to Reproduce:
1. put the files in the attachment into a directory
2. Open up Mozilla
3. go to the directory where you put the files from the attachment
4 [review]. select "index.html"
5. In the left frame, click on "link"
6. When the right hand frame loads, click on the text entry control.
   Attempt to enter "asdf".

Actual Results:  
In the status bar I first get the message:
   Link not found: "aa"
and similar additional errors as I enter the text.

Expected Results:  
The text should have appeared in the text entry box.

I was also able to reproduce this error on a Solaris 8 machine using
   Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7a) Gecko/20040303
and Mozilla 1.6.
I also reproduced the error with Mozilla 1.5 and 1.6 on my Windows machine.
I was not able to reproduce the error with Mozilla 1.4.1 on my Windows machine.
I downloaded all of these from the page http://mozilla.org/releases/

If I use SAXON to generate the HTML, and then change the index.html to load
the HTML rather than the XML this problem does not occur.
Attachment contains 5 files:
index.html	- defines two frames
left-frame.html - has a link that will cause "right-frame.xml" 
		  to be loaded into right-hand frame
right-frame.xml
right-frame.xsl - style sheet to turn the XML into HTML with the form
right-frame.dtd
Assignee: events → peterv
Component: Event Handling → XSLT
QA Contact: ian → keith
Whiteboard: DUPEME
* An HTML-Page that is created by the browser's internal XSLT-Processor
an that contains form input (textarea, input, ...) does not allow any keyboard
input (on first load).
* After refresh (page reload) everything works fine.
* Also, running the source document (XML) through an external XSLT
processor and opening the resulting HTML-Document works fine.
* DOM-Inspector verifies that (internally) generated HTML-Doc is ok,
i. e. exactly what is expected.
* An HTML-Page that is created by the browser's internal XSLT-Processor
an that contains form input (textarea, input, ...) does not allow any keyboard
input (on first load).
* After refresh (page reload) everything works fine.
* Also, running the source document (XML) through an external XSLT
processor and opening the resulting HTML-Document works fine.
* DOM-Inspector verifies that (internally) generated HTML-Doc is ok,
i. e. exactly what is expected.
* Bug reproduced on Win32, Firefox 0.8 and Mozilla 1.6
Attachment #144948 - Attachment is obsolete: true
OS: Windows 2000 → All
Hardware: PC → All
I get a similar bug with browser-side XSLT-generated forms. I can paste data
into a form field and I can change focus from one field to another but I can't
get any typed text to go into a text field.

This is really important to me - it will mean I have to do server-side XSLT for
my code to work properly, much higher server load.

I can confirm that the bug still exists in Mozilla 1.7b on Win XP.
On more thing... the bug only occurs for me when I change focus away from the
problem window and come back again: either by clicking on another tab, or
clicking on another Mozilla window, or even to a non-Mozilla window (eg windows
explorer)

And sometime refresh/reload doesn't fix the problem, you have to refresh more
than once.
The problem also happens at http://www.patrick-brennan.com/xml/photo_album.xml
but doesn't need frames to reproduce. Try entering text into the text field,
change to a new window, and go back to this page. You won't be able to backspace
the text. Refreshing the page will reset the form values though (which is also
unexpected).

I've reproduced this in a nightly build less than a week old as well as Firefox 0.8.
If you have a smaller testcase then the one attached, please make it as small as
possible and attach it to this bug.
I have made a similar testcase as the last testcase which was made here:
http://home.hccnet.nl/m.wargers/test/mozilla/XML_XLT_form_input/test.xml
http://home.hccnet.nl/m.wargers/test/mozilla/XML_XLT_form_input/

But I have also added a button with a window.focus method to it.
When typing in the textarea does not work anymore, you can press the
window.focus() button and then you can type again.
Please people, _attach_ means _attach_to_this_bug_, not provide a url. And the
smaller the testcase the easier to find the bug.
Thinking my original attachment is already "quite minimal"...
I've added another version, because I want to make clear that
the "window.focus()-trick" does not work, but "reload" does.
So I've added two buttons:
  1. window.focus()
  2. submit (action = test.xml, not /apps/FormMail/FormMail.pl )

Hope that helps

Axel
Blocks: 241106
Removing the ESM patch from bug 198153 should fix this bug. I've tested it and
it works.
See also bug 241942, comment 3.
Just a note, I do not believe backing out the ESM patch in question is the right
fix here.  There is likely a deeper problem.  See also the analysis in bug 241942.
I have noticed that this bug also applies to IFRAMES.  If two iframes are on the
screen, both containing forms, going from one form to the other using the mouse
triggers this bug.  Hitting refresh or switching to another application will
allow you to edit one form, but when you go to the next one it starts again. 
This applies only when the forms are XSLT generated.  I will attach a testcase
if needed.
*** Bug 252596 has been marked as a duplicate of this bug. ***
*** Bug 253992 has been marked as a duplicate of this bug. ***
Also seen on :
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040225 Firefox/0.8 and
RedHat 9
Just for the records...
* Can no longer reproduce the bug using the simple testcase (no frames)
  on current mozilla/firefox releases (1.7.*/0.9.*)
But...
* The bug persists when using frames (and probably iframes)
* Last tested release: firefox 0.9.3 on (gentoo-)linux	
* Testcase validated with Xalan(-C)

Axel
This is a stripped down XML source file to demonstrate the bug. It only
contains a single <test/> node. The stripped-down debug2.xsl it refers to is in
another attachment.
This is the XSLT file to accompany the previous debug2.xml attachment. This
file
only uses one directive, <xsl:template match="/test">, to output some embedded
html for a minimal form with one select input.
I have posted 2 attachments (158501,158502) that, I believe, demonstrate this
bug in its simplest form. The attached XML file contains a single <test/> node and
the attached XSLT that it refers to uses a single <xsl:template match="/test">
directive to output some embedded HTML for a minimal form with a single select
input.

To reproduce the bug, download both the XML and XSLT attachments then load the
XML file in any version of mozilla or firefox. The select pulldown menu often
operates correctly, but will reproducibly fail if you highlight the URL in the
navigation toolbar (either by clicking on it directly or by TAB-ing a few times)
immediately after loading the page. When it fails, the pull-down menu is
rendered, but any selection is ignored.

As a sanity check, extracting the HTML embedded in the XSLT file into a separate
file works as expected.

This bug is a real nuisance for me since it effectively means I cannot use
client-side XSLT to generate forms. I am sorry I cannot be more help!
Critical for B2B applications. I guess, severity should be changed to major,
because form operations are very important function of browser.
it would be great if someone could find a regression date for this
(In reply to comment #22)
> it would be great if someone could find a regression date for this
The first testcase ("five files used to demonstrate problem.") works in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030902
But it doesn't work in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916

Like I said in comment 11 (and bug 241942, comment 13), the ESM patch from bug
198153 seems to cause this bug.
I recently ran across this bug.  If you have the web developer plugin installed
you can right click on the offending input and select "Web
Developer/Forms/Convert Gets to Puts" and you can continue to type in the
input... this is obviously not a fix, but may be some sort of insight into the
problem (in my case I'm only using puts, so changing from gets to puts does
nothing but continues to let me type)

Kris
Thanks for suggestion.

But we may not explain to our customers that working with our B2B/B2C web
interface they should take shaman-like actions to enter data in forms :(
This same bug seems to manifest when creating form input elements via
DOM/Javascript. It's *killing* us at work. 
Gavin, could you create a small testcase demonstrating that? If that's the case
this isn't an XSLT bug at all.
Unzip the attachment, and load bug_236596_test.xml with Firefox. Follow the
directions on the page to reproduce the bug. It is a very simple example that
shows that if you click into an iFrame, then back into a textarea, you will not
be able to type into the textarea.

Now load bug_236596_test.html in that same directory, and you will see the
problem is no longer exhibited. It is only when the form is drawn with XSLT.
more xslt testcases isn't needed. However if someone could create an
DOM/Javascript one as claimed in comment 26 that would be very helpfull.
I'm sorry, the other examples I tried seemed not too simple.

We have a whole slew of people reporting this problem with XSLT with examples.
Then we have one person saying it "seems" to be related to DOM/JavaScript (how
exactly is it related?), who has never replied with a followup. Perhaps he was
wrong?

So unless someone can post an example of form elements being created with
DOM/JavaScript, exhibiting this problem, what would the next step be in trying
to debug the issue in XSLT? 

The sample cases I uploaded show the same exact form being loaded, once via
XSLT, and once as normal HTML webpage, and only the XSLT version has the
focusing problem. Now, I don't understand the intricacies of the Mozilla
codebase, so could someone explain how that is related to JavaScript?

Maybe we can come up with a DOM/JavaScript example if it really is related.
Yes, the dom/javascript problem might not exist, or if it does it might not be
related. Which is exactly why I'm asking for a testcase.

I currently don't have the time for any development or bugfixing (if I did this
bug would be at the top of my list), however if there's a DOM/Javascript problem
I can forward the bug to the people that do have time.
I have created a modified version of the HTML page included in my last example.
I replaced the explicit <textarea> code with some javascript that creates a
textarea using DOM and then adds it to the existing form. 

The bug exhibited here does NOT show up in this example. This doesn't prove
there is no problem with DOM/Javascript created form elements, but it at least
shows there is definitely no problem in this simple case, unlike in the simple
case shown for XSLT.
I have a workaround that I put in place until this bug gets fixed.

Add onclick="window.focus();this.focus();" to all of your INPUT tags on any
affected pages.

This seems to work, and I have seen no adverse effects (Other than having to add
this to every INPUT).
(In reply to comment #33)
> Add onclick="window.focus();this.focus();" to all of your INPUT tags on any
> affected pages.

Awesome! Thank you! I confirm that this workaround seems to work with no side
effects!
Sorry to disturb your party, but as I've already pointed out...
... the problem persists. At least when using frames.

--Axel
Axel, I just tried your test case, and it is working fine for me. I then took
the workaround code out, and confirm that it doesn't work without it. What steps
are you performing with the new code where it is still not working?
AAARGH!

The workaround did not work for me, because of my restrictive java-script
settings, i. e. "Raise or lower windows" was unchecked!

May I join the party?

--Axel
(Now busy with coding, i. e. adding the work-around to my XSLTs)
Attached file js workaround (obsolete) —
Keep your XSLT clean! Just add a the following line to somewhere, for example
to the <head> tag of your generated html:
<script type="text/javascript" src="bug236596workaround.js"></script>
Attachment #171339 - Attachment is obsolete: true
Attached file js workaround
(In reply to comment #38)

> Keep your XSLT clean! Just add a the following line to somewhere, for example
> to the <head> tag of your generated html:
> <script type="text/javascript" src="bug236596workaround.js"></script>

OK this sounds like a great workaround improvement, but we weren't able to get
it to work. Yep, we are using the second attachment with the fixed (input.type
== 'text') code. We are calling the javascript include from within the HEAD tags
that our XSL is set to output, i.e.:

<head>
<script type="text/javascript" src="focustrick.js"></script>
</head>

But the bug is still showing up. If we take that out and put the onClick=""
workaround in each input tag, that works fine.

Has anyone gotten the above workaround to work? If so, can we see how you're
calling the js include?
Attached file js workaround v1.01
It really works but doesn't with <select> and <textarea> elements. I would
propose my version to use XPath to select all affected elements.
This XSL file demonstrates the focus bug *with javascript* creating the DOM
elements.
tiny xml file that includes the xsl file that shows the bug
OK, I have submitted some attachments that show the bug. Here's what I've observed:

1) Creating input fields via javascript and the DOM in HTML does NOT trigger the
focus bug.
2) If XSL is used to create the HTML, then the exact same javascript, while it
still creates the input files just fine, WILL cause the focus bug.
3) If the XSL contains a <p> tag with some text before the button element, the
bug does not manifest. Joy!!

3 is a kind of work around, I suppose. Hope this helps.
Attached patch patch to fix (obsolete) — Splinter Review
Assignee: peterv → bugmail
Status: NEW → ASSIGNED
Attachment #173339 - Flags: superreview?(peterv)
Attachment #173339 - Flags: review?(peterv)
Comment on attachment 173339 [details] [diff] [review]
patch to fix

Actually, on second though, this is better done in the DocumentViewer
Attachment #173339 - Flags: superreview?(peterv)
Attachment #173339 - Flags: review?(peterv)
Attached patch Patch v2Splinter Review
This is a better fix since we're not always going to replace the sourcedocument
with the resultdocument (think script). So this only sets the container when we
do.
Attachment #173431 - Flags: superreview?(peterv)
Attachment #173431 - Flags: review?(peterv)
*** Bug 241106 has been marked as a duplicate of this bug. ***
*** Bug 221371 has been marked as a duplicate of this bug. ***
*** Bug 227173 has been marked as a duplicate of this bug. ***
Comment on attachment 173431 [details] [diff] [review]
Patch v2

Sweet.
Attachment #173431 - Flags: superreview?(peterv)
Attachment #173431 - Flags: superreview+
Attachment #173431 - Flags: review?(peterv)
Attachment #173431 - Flags: review+
Fix checked in. Everyone that has attached testcases to this bug, or that has
filed duplicates, please check that the problem is fully fixed now. I have
tested some of the testcases, but the problem was never fully reproduceable on
my mashine.

If you've filed a dup and it seems to be fixed now please mark the dup verified,
or, if you don't have permission to do so, state in the bug that you have tested
so we can mark it.
Same goes for this one. If it seems fixed please mark verified.

Of course, do let us know if things aren't fixed too, preferably by reopening
the bug. But test on tomorrows nighly build.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Tested nightly build (2005-02-07)
   firefox-1.0+.en-US.linux-i686.installer.tar.gz
on gentoo linux, using my test-cases and some more XSLT genrated forms.

Can confirm that the bug no longer persists, i. e. even when
"frames appear on the scene" keybaord focus is now handled
correctly.

Hope that the patch is marked stable soon.

Thanks a lot

--Axel
Marking verified per axels comments.
Status: RESOLVED → VERIFIED
Comment on attachment 173431 [details] [diff] [review]
Patch v2

Requesting approval to land on branches. This fixes a pretty serious bug in
XSLT generated pages.

The patch is very low risk since it only has effect on XSLT generated pages.
Attachment #173431 - Flags: approval1.7.6?
Attachment #173431 - Flags: approval-aviary1.0.1?
Oh, I wanted to remind people that if you've filed a bug that is marked a
duplicate of this one, please test if those bugs have been fixed now and let us
know the result (in those bugs, not in this one).

Of course, anyone is welcome to retest those testcases, not just the people that
filed the bug.
This worked for me on both my submitted sample and in my production applications.
Comment on attachment 173431 [details] [diff] [review]
Patch v2

a=mkaply for 1.7.6.
Attachment #173431 - Flags: approval1.7.6? → approval1.7.6+
Keywords: fixed1.7.6
Whiteboard: DUPEME
checked into 1.7 branch. Still awaiting aviary approval
Comment on attachment 173431 [details] [diff] [review]
Patch v2

a=asa for 1.0.1 checkin.
Attachment #173431 - Flags: approval-aviary1.0.1? → approval-aviary1.0.1+
Checked in no aviary. This bug should now be fixed in all comming mozilla and
firefox releases.
Erm.. that should be "Checked in *to* aviary"
I am in GNU-Hell here. This bug is marked fixed in 1.7.6, but the firefox
download seems to be giving me 1.7.5. Is this really fixed? Does the fixed
version exist?

Additionally bug 276535 looks like a dupe of this one.
1.7.6 hasn't been released yet, it will be soon. Nightlies have the fix.
*** Bug 276535 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.