This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This pages: http://w3c-test.org/framework/test/dom4-Ms2ger-submissions/single/Element-childElement-null.svg/ Results in: WARNING: Invalid argument supplied for foreach() File: /u/www.w3c-test.org/framework/lib/Format.php Line: 36 Context: Array ( [formatName] => html [formatNames] => ) #0 Page->writeHTMLError() called at [/u/www.w3c-test.org/framework/core/DynamicPage.php:206] #1 DynamicPage->writeHTMLError() called at [/u/www.w3c-test.org/framework/core/Page.php:1681] #2 Page->errorHandler(2, Invalid argument supplied for foreach(), /u/www.w3c-test.org/framework/lib/Format.php, 36, Array ([formatName] => html,[formatNames] => )) called at [/u/www.w3c-test.org/framework/lib/Format.php:36] #3 Format::FormatNameInArray(html, ) called at [/u/www.w3c-test.org/framework/pages/TestCasePage.php:432] #4 TestCasePage->writeReferenceAndFormatTabs() called at [/u/www.w3c-test.org/framework/pages/TestCasePage.php:603] #5 TestCasePage->writeBodyContent() called at [/u/www.w3c-test.org/framework/core/Page.php:1558] #6 Page->writeHTMLBody() called at [/u/www.w3c-test.org/framework/core/Page.php:1438] #7 Page->writeHTML() called at [/u/www.w3c-test.org/framework/core/Page.php:1356] #8 Page->write() called at [/u/www.w3c-test.org/framework/core/Page.php:69] #9 Page::RunPage(TestCasePage) called at [/u/www.w3c-test.org/framework/testcase.php:21] Get: Array ( [s] => dom4-Ms2ger-submissions [c] => Element-childElement-null.svg [o] => 1 ) Cookie: Array ( [crumbs] => test cookie )
Same problem here: http://w3c-test.org/framework/test/dom4-Ms2ger-submissions/single/Element-childElementCount-dynamic-add.svg/
Incidentally, I flipped on the debug setting in the framework local config file with the intention of keeping it on to troubleshoot this bug (and flipping it back off as soon as we don't need it any longer).
At first blush this looks like it may be an issue with the format data in the database. Is there any way of accessing the underlying MySQL db on the server, say a phpMyAdmin instance? If not, can we get this installed and give me access to the framework's database?
(In reply to comment #3) > Is there any way of accessing the underlying MySQL db on the server, say a > phpMyAdmin instance? If not, can we get this installed and give me access to > the framework's database? I set it up and sent you the details via direct message on IRC.
Ok, the problem here was the format data in the `testpages` table was wrong for the SVG tests, the format was set to 'svg ' instead of 'svg' (note the trailing space). I corrected the data in the DB and all the SVG tests for this suite are working now. Mike, I'm transferring this to you to find out how the DB got bad data to begin with. Perhaps an error in the admin pages? When you're done checking that, please send this back to me as an enhancement request. I'll add better error handling/reporting at the very least. I don't believe I want to make the DB tolerant of spaces in that field as it can be used for joins. In general, that test suite isn't using the formats properly, rather than each test having three instances, one in each format, there should only be one instance of each test, with all three formats available. IE, rather than 'test.svg', 'test.html', 'test.xhtml', there should only be 'test' without the extensions in the test name. I understand that the framework currently merges all results across all formats for each test, if that's not desired behavior for this suite (and perhaps why the tests were entered separately, then we should add an option for the suite to track the results differently instead.
(In reply to comment #5) > Mike, I'm transferring this to you to find out how the DB got bad data to begin > with. Perhaps an error in the admin pages? I've just looked through the admin pages and I can't find a reason why this would go wrong. There is no hardcoded mention of SVG, nothing that would seem to add a space (especially not to just one of the format names). What's more, performing the same import on my local copy of the code does not generate the bug. If this bug shows up again we'll investigate further, but if it doesn't I think we should assume that it was something temporary that corrupted the data once but that's since been fixed. > When you're done checking that, please send this back to me as an enhancement > request. I'll add better error handling/reporting at the very least. I don't > believe I want to make the DB tolerant of spaces in that field as it can be > used for joins. I agree that the DB shouldn't be made tolerant of any manner of faulty data, but what we can do is improve detecting it on input. I've already made a few such defensive changes (notably: it was impossible to run the system on an empty DB because some features assume there's data; this should now be better though perhaps not perfect since I added data in the process of fixing some of those issues). > In general, that test suite isn't using the formats properly, rather than each > test having three instances, one in each format, there should only be one > instance of each test, with all three formats available. IE, rather than > 'test.svg', 'test.html', 'test.xhtml', there should only be 'test' without the > extensions in the test name. I understand that the framework currently merges > all results across all formats for each test, if that's not desired behavior > for this suite (and perhaps why the tests were entered separately, then we > should add an option for the suite to track the results differently instead. I'm not sure what Ms2ger intended here, but I suspect that you're right and the intent is to test the functionality on a given format if it's supported — not to test the same thing in three different settings. I'll check with him.
(In reply to comment #6) > (In reply to comment #5) > > Mike, I'm transferring this to you to find out how the DB got bad data to begin > > with. Perhaps an error in the admin pages? > > I've just looked through the admin pages and I can't find a reason why this > would go wrong. There is no hardcoded mention of SVG, nothing that would seem > to add a space (especially not to just one of the format names). What's more, > performing the same import on my local copy of the code does not generate the > bug. If this bug shows up again we'll investigate further, but if it doesn't I > think we should assume that it was something temporary that corrupted the data > once but that's since been fixed. Yeah, I think that is case. This suite is one that I was using early on as a case of a test suite that had only a very minimal manifest file format, and the bug reported with the SVG test cases was probably just a remnant of me flubbing something in the initial import.