Open Bug 714781 Opened 13 years ago Updated 2 years ago

[BC] Tables: Border rendering inconsistencies between inline CSS and CSS set from script

Categories

(Core :: Layout: Tables, defect)

x86
Windows 7
defect

Tracking

()

People

(Reporter: matthieu.rivaud+bmo, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: testcase)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0a2) Gecko/20120101 Firefox/11.0a2 Build ID: 20120101042005 Steps to reproduce: I recently encountered a strange rendering artifact when working on tables, and finally reduced the test-case as in the attached HTML file. Note that you have to trigger a repaint to see the strangeness (by changing tab and back for instance). I provided a mean to force a repaint in the test-case by changing the font color of the body element. I managed to repeat the issue on the following builds (with and without HA, for good measure): - Firefox 12.0a1 (http://hg.mozilla.org/mozilla-central/rev/b87861e50640) - Firefox 11.0a2 (http://hg.mozilla.org/releases/mozilla-aurora/rev/e2fe885dce01) - Firefox 3.6.15 (http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c2b88342ea2b) I did not test current release/beta. FWIW, neither IE 9.0.8112.16421 nor Chrome 16.0.912.63 m shows this behavior. Regards, Actual results: - The touched cell border turns blue (expected) - After a repaint, close cells without border begin to show one (unexpected)
Attachment #585402 - Attachment mime type: text/plain → text/html
Component: General → Layout: Tables
QA Contact: general → layout.tables
Version: 12 Branch → Trunk
I revised my test-case in an attempt to get closer to the original script I wrote (which was setting the cell class on the fly, not the border). This new test-case thus demonstrates the differences between setting the class by script (and repaint), and the reference table with the class defined in the markup. Regards,
Attachment #585674 - Attachment mime type: text/plain → text/html
Keywords: testcase
Hi, This bug has not seen any activity since triage ~3 weeks ago. Does it miss some information on my end ? Do I need to do something to help it gain some attention ? Is there some more investigation I can/must do in order to make this bug advance ? Regards,
My guess is that the start bit http://mxr.mozilla.org/mozilla-central/source/layout/tables/celldata.h#262 in the cell left border entries gets reset for the row above the blue cell while it shouldn't. This mechanism should go away in bug 540256. >This bug has not seen any activity since triage ~3 weeks ago. 1. This is table layout, it is slow due to man power constraints. >Do I need to do something to help it gain some attention ? 2. Attach a patch to fix it and ask for review. I usually review within a week if not a day. (small hint: I am talking about a 40+ hours work patch here. So don't take it to literal, but I a promise to mentor any table layout bug if you decide to work on it) >Is there some more investigation I can/must do in order to make this bug advance ? 3. Learn as fast as you can C++ to overcome 1 and come into reach of 2.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Tables: Border rendering inconsistencies between inline CSS and CSS set from script → [BC] Tables: Border rendering inconsistencies between inline CSS and CSS set from script
(In reply to Bernd from comment #3) > 1. This is table layout, it is slow due to man power constraints. No problem ... It's just that I'm used to see bz hop in almost every bug out there and at least give pointers ^^ ... I feared the bug had just been unnoticed due to poor bugzilla skills on my end ... > 2. Attach a patch to fix it and ask for review. I usually review within a > week if not a day. (small hint: I am talking about a 40+ hours work patch > here. So don't take it to literal, but I a promise to mentor any table > layout bug if you decide to work on it) I would gladly do that in my free time, but I feel I have a big hurdle to overcome : I first need to get Firefox to compile and tests to run on my Win7 box (MS2010). I do not have any experience of makefiles, moz automated tests, etc. I do not have python installed on any of my computers, and never even used a py script. I guess I could learn all that, but that just adds to the initial estimation (I must precise I am quite lazy ^^). Maybe I could ask my brother (Julien) to give me a linux vbox with everything setup :p > 3. Learn as fast as you can C++ to overcome 1 and come into reach of 2. I do know C/C++ quite a bit, even if my skill are rusty (I haven't touched a C++ line of code in 8 years I think)
Also, I'm not even sure it's a layout bug, because one must trigger a repaint to see the unexpected borders, and the painting of these borders is somewhat intermittent (when one scrolls, the borders may or may be painted, leading to kind of dashed borders sometimes, if the scroll is slow enough). A full repaint always exhibits the bug (by CTRL-tabbing or ALT-tabbing for instance).
(In reply to Matthieu Rivaud from comment #5) > [...] may or may [...] May or may *not*, obviously ...
As Matthieu has noted on that bug https://bugzilla.mozilla.org/show_bug.cgi?id=672167 may well be the same bug.
Blocks: 771062
depends on bug 540256 per comment 3
Depends on: 540256
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: