User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 In the HTML/CSS supplied, the editable text shown in the text boxes (file upload fields as well) is rendered at the left of the page rendering area. The text should be rendered within the input element -- it also renders the text in other extremities (not visible) based on the left/right alignment of the table wrapping the input elements. Occurs in Firefox and Mozilla browser. respectively: (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3) (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050419). Reproducible: Always Steps to Reproduce: 1. view HTML attached -- text inputs display correctly 2. with HTML attached -- remove the /* */ from around the css class selector: ".type:first-line" 3. view HTML attached -- text inputs display incorrectly Actual Results: 1. text of input elements appears within the actual input elements 2. -- 3. text of input elements appears at top left of rendering area, or not visible at all. physical text elements are in the correct position Expected Results: Should have rendered text of input elements within the physical input element Perhaps something to do with nesting lists within tables? Nesting as follows: table -> tr -> td -> [ul -> li's ->] ul -> li's -> input element ^ I have tried removing these and rendering is still incorrect.
Created attachment 181236 [details] HTML file of input elements rendering text correctly See instructions to reproduce bug... This HTML displays correctly without ".type:first-line " being used...
A minimal testcase would be nice...
Created attachment 183796 [details] minimal failing test case
Created attachment 245372 [details] [diff] [review] Fix The problem is that when we put the input inside the first-line we don't set the HAS_CHILD_WITH_VIEW flag on it, so we don't reposition the view when we reposition the inner table. As a result, OffsetTo() lies all over, and when painting we decide that some frames are just outside the dirty region... and don't paint them (used to paint them in totally the wrong place). It might be worth fixing this on 1.8, I think....
Created attachment 245373 [details] Testcase without form controls that shows views are the only problem
Daniel, sorry this took so long to get to. :( The testcase was incredibly helpful, though!
11 years ago
10 years ago
Added the tests to reftest.