This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Fantasai has proposed alterations to the test case selection UI of the test harness. This proposed redesign needs to be finalized and implemented. Fantasai is working out some issues with the proposal, including radio button usage and text field sizing. Also, fantasai will complete cross browser testing of the proposed interface design. David Berfanger will then integrate the design in the harness code base.
Created attachment 569 [details] updated template
Is the user-agent text field to small? Still needs means of providing user agent mode (Bug: 5957).
Proposed template assumes that the harness has the concept of test formats. Adding dependency on bug 6022, requesting that this concept be added.
It has been proposed that individual tests can belong to more than one test group (bug 6023). This enhancment affects how the selection lists of the proposed template are populated. Adding dependency on bug 6023.
Wrt dependency on 6022, I think you can just comment that part out for now. It doesn't need to block this fix. Wrt 6023, I don't think that needs to affect what the template looks like, it just affects the back-end that generates it. Also should not be considered blocking.
Created attachment 585 [details] revision proposal Selecting, for example, an entry in the test selection list leaves any previous selection in the group selection list active. The selection lists are more prominent than the radio buttons, and this behavior seems to cause confusion regarding which selection is active. I'm wondering if enabling and disabling the selection lists with radio button changes would be a better approach? See attached.
We need to finalize the UI component for entering for what UA mode are data being provided.
With the proposed interface, it is not guaranteed that each test format in a particular suite will have the same number of test cases; thus, we should change the first radio button to say "All tests" rather than, for example, "All 511 tests."
Created attachment 586 [details] proposed template v2.0 How's this? Changes I made: - tweaked scripting to do disabling dynamically (so nothing's permanently disabled if you have scripting turned off) - scripted the User-agent string field to also be disabled - added a CSS opacity rule to make disabled fields look even more disabled - added a Mode field - reordered and relabeled options a bit Comments?
Created attachment 587 [details] another revision proposal Similar issues to those already discussed are present when considering the controls for providing an alternate user agent string. That is you can enter a ua string but fail to check the radio button that would make that entry valid. Suggesting enabling and disabling the text field for entering a new ua string according to which radio button is selected. Separately, the form controls needed additional mark-up to make them functional with respect to providing posted data.
(In reply to comment #9) > Created an attachment (id=586) [details] > proposed template v2.0 > How's this? Changes I made: > - tweaked scripting to do disabling dynamically (so nothing's permanently > disabled if you have scripting turned off) > - scripted the User-agent string field to also be disabled > - added a CSS opacity rule to make disabled fields look even more disabled > - added a Mode field > - reordered and relabeled options a bit > Comments? Missed this previously. Disregard my last proposal. Will look at the new updates presently.
Created attachment 588 [details] proposed template v2.1 Got some feedback already, heh.
Created attachment 589 [details] revision proposal 2.1.1 Added markup to the from controls to make them functional with respect to providing correctly posted data. I'm not sure I understand how the mode Other is supposed to work. The dynamic disabling breaks when returning to the page using the browsers back button, disabling the selection box while leaving the radio button checked.
Created attachment 590 [details] proposed template v2.2 A few minor fixes to the UA string styling. Would it be possible to grab the least of the three and say e.g. All 511+ tests? Or maybe it's better to leave it out. I'm ok either way.
Other doesn't do anything, it's just a label. If someone picks it, it means we're probably missing something from the list. But at least their results aren't getting mixed up with those of another mode. I'll make a diff of my style changes so we can apply them to your form fixes. Wrt dynamic stuff.. it works on FF. :/ Maybe the <script> element isn't triggering in other browsers?
Created attachment 591 [details] proposed template v2.3 Merged changes. Also added 'type' attribute to <script> ... does the state work with the back button now?
Created attachment 592 [details] proposed template v2.3.1 Tweak some margins etc.
(In reply to comment #16) > Created an attachment (id=591) [details] > proposed template v2.3 > Merged changes. Also added 'type' attribute to <script> ... does the state work > with the back button now? No, neither IE6 of IE7 handle state correctly with the back button. Indeed, no problems with FireFox.
Created attachment 595 [details] A couple of minor changes I had put one of the hidden <input> tags directly in the <form> such that the HTML didn't validate. Moving it one line down into the first <div> fixes that problem. Also, moving the <SCRIPT> code into the onload of the <BODY> seems to fix the IE state problem. Also, Firefox still works.
Created attachment 596 [details] Yet another change for IE (proposed template v2.3.3) Even though v.2.3.2 validates IE still seems to think there is a coding error on the page. Looks to be related to thinking that the scripts are unterminated strings. I'm thinking IE doesn't like the strings to wrap lines. Perhaps, we can fix this problem by defining a javascript function in the <head> and using this scirpt for onload, onclick, and onchange events.
Created attachment 597 [details] Template v2.3.3 - as implemented in my testbed Here is the output from my test bed implementing the new interface as proposed in template version 2.3.3. This uses the group names and test case names parsed from testinfo.data about two days ago. Check to make sure that the naming scheme works. If all is well, I will mark this bug as resolved after the next code check in.
I prefer the mode names from the template rather than the output here. Also the ordering in the template should be kept: Normal screen followed by Handheld screen, etc.