Closed Bug 236596 Opened 18 years ago Closed 17 years ago
form element cannot get focus when loaded by XML/XSLT page
20.00 KB, application/x-tar
968 bytes, application/zip
1.11 KB, application/zip
1.29 KB, application/x-gzip
89 bytes, text/xml
445 bytes, text/xml
2.06 KB, application/x-zip-compressed
1.19 KB, text/html
1.32 KB, application/x-gzip
410 bytes, text/plain
439 bytes, text/plain
579 bytes, text/plain
85 bytes, text/plain
2.49 KB, patch
|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
* 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
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
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 :(
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.
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)
It really works but doesn't with <select> and <textarea> elements. I would propose my version to use XPath to select all affected elements.
tiny xml file that includes the xsl file that shows the bug
Comment on attachment 173339 [details] [diff] [review] patch to fix Actually, on second though, this is better done in the DocumentViewer
Attachment #173339 - Attachment is obsolete: true
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.
*** 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.
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.
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+
No longer blocks: 241106
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.