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

Status: VERIFIED FIXED

(Core :: XSLT, defect)

Description

[Jeffrey G. Lewis]

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.

Comment 1

[Jeffrey G. Lewis]

Attachment: five files used to demonstrate problem.

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

Comment 2

[Axel Dyks]

Attachment: Minimal XML/XSL/DTD-Example that demonstrates the same problem.

* 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.

Comment 3

[Axel Dyks]

Attachment: Minimal XML/XSL/DTD-Example that demonstrates the same problem

* 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

Comment 4

[John Pye]

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.

Comment 5

[John Pye]

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.

Comment 6

[XFox]

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.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

If you have a smaller testcase then the one attached, please make it as small as
possible and attach it to this bug.

Comment 8

[Martijn Wargers (dead)]

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.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Please people, _attach_ means _attach_to_this_bug_, not provide a url. And the
smaller the testcase the easier to find the bug.

Comment 10

[Axel Dyks]

Attachment: My "original test case" with 2 additional buttons

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

Comment 11

[Martijn Wargers (dead)]

Removing the ESM patch from bug 198153 should fix this bug. I've tested it and
it works.
See also bug 241942, comment 3.

Comment 12

[Brian Ryner (not reading)]

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.

Comment 13

[Kenneth Bogert]

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.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

*** Bug 252596 has been marked as a duplicate of this bug. ***

Comment 15

[Ng Tung]

*** Bug 253992 has been marked as a duplicate of this bug. ***

Comment 16

[mathieu]

Also seen on :
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040225 Firefox/0.8 and
RedHat 9

Comment 17

[Axel Dyks]

Attachment: XML/XSLT testcase using frames (form focus/keyboard input fails)

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

Comment 18

[David Kirkby]

Attachment: XML source for stripped-down test case

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.

Comment 19

[David Kirkby]

Attachment: XSLT for stripped-down test case

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.

Comment 20

[David Kirkby]

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!

Comment 21

[Raoul Nakhmanson-Kulish]

Critical for B2B applications. I guess, severity should be changed to major,
because form operations are very important function of browser.

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

it would be great if someone could find a regression date for this

Comment 23

[Martijn Wargers (dead)]

(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.

Comment 24

[Kris Vanderwater]

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

Comment 25

[Raoul Nakhmanson-Kulish]

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 :(

Comment 26

[Gavin Doughtie]

This same bug seems to manifest when creating form input elements via
DOM/Javascript. It's *killing* us at work. 

Comment 27

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Gavin, could you create a small testcase demonstrating that? If that's the case
this isn't an XSLT bug at all.

Comment 28

[Thomas Winzig]

Attachment: Another example showing the problem simply

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.

Comment 29

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 30

[Thomas Winzig]

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.

Comment 31

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 32

[Thomas Winzig]

Attachment: An example using DOM that does NOT show a bug

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.

Comment 33

[shholmes7]

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).

Comment 34

[Thomas Winzig]

(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!

Comment 35

[Axel Dyks]

Attachment: added onclick ...focus() to my testcase using frames

Sorry to disturb your party, but as I've already pointed out...
... the problem persists. At least when using frames.

--Axel

Comment 36

[Thomas Winzig]

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?

Comment 37

[Axel Dyks]

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)

Comment 38

[Földényi Tamás]

Attachment: js workaround

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>

Comment 39

[Földényi Tamás]

Attachment: js workaround

Comment 40

[Thomas Winzig]

(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?

Comment 41

[Raoul Nakhmanson-Kulish]

Attachment: 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.

Comment 42

[Gavin Doughtie]

Attachment: XSL file that demos the focus bug

This XSL file demonstrates the focus bug *with javascript* creating the DOM
elements.

Comment 43

[Gavin Doughtie]

Attachment: Source file that includes the xsl file for demoing bug

tiny xml file that includes the xsl file that shows the bug

Comment 44

[Gavin Doughtie]

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.

Comment 45

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: patch to fix

Comment 46

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 173339 [details] [diff] [review]
patch to fix

Actually, on second though, this is better done in the DocumentViewer

Comment 47

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: Patch v2

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.

Comment 48

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

*** Bug 241106 has been marked as a duplicate of this bug. ***

Comment 49

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

*** Bug 221371 has been marked as a duplicate of this bug. ***

Comment 50

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

*** Bug 227173 has been marked as a duplicate of this bug. ***

Comment 51

[Peter Van der Beken [:peterv]]

Comment on attachment 173431 [details] [diff] [review]
Patch v2

Sweet.

Comment 52

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 53

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 54

[Axel Dyks]

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

Comment 55

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Marking verified per axels comments.

Comment 56

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 57

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 58

[Gavin Doughtie]

This worked for me on both my submitted sample and in my production applications.

Comment 59

[Mike Kaply [:mkaply]]

Comment on attachment 173431 [details] [diff] [review]
Patch v2

a=mkaply for 1.7.6.

Comment 60

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

checked into 1.7 branch. Still awaiting aviary approval

Comment 61

[Asa Dotzler [:asa]]

Comment on attachment 173431 [details] [diff] [review]
Patch v2

a=asa for 1.0.1 checkin.

Comment 62

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Checked in no aviary. This bug should now be fixed in all comming mozilla and
firefox releases.

Comment 63

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Erm.. that should be "Checked in *to* aviary"

Comment 64

[Bill Kuker]

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.

Comment 65

[Peter Van der Beken [:peterv]]

1.7.6 hasn't been released yet, it will be soon. Nightlies have the fix.

Comment 66

[Peter Van der Beken [:peterv]]

*** Bug 276535 has been marked as a duplicate of this bug. ***