these gifs show up with the words 'clear' and 'bolt'

ari: Which page, exactly? The http://www.flexmind.com/ page does not mention "clear.gif" nor "bolt.gif". Note that the problem is probably that the page is referring to some non- existant files, so we are (correctly) showing the alt text instead.

This is like bug 32351. py8ieh, it's "IMO correctly", not "correctly". Lots of people (including me) disagree with you on which font should be used, whether a border should be drawn around the text, and whether the page's width= and height= should take precedence over the length of the text.

If you want it drawn in some other way, then that is what CSS is for. Given no styles (the default) then the alt text should, per HTML4 and CSS2, be drawn inline just like if it was in a SPAN.

You really can't expect all website authors to go out and learn CSS, and then apply it to all of their old broken pages (and pages on slashdot-effect-prone servers, and pages that might be displayed by people who have images turned off). Also, old browsers followed old standards by displaying broken images in a rational way. I don't mind if ALTs get displayed as normal text on pages that specify dtd as strict 4.0, but they shouldn't be on pages where the exact standard can't be determined.

If those pages render fine in Lynx, then our rendering will be fine too (in fact our alt text handling is better than Lynx's right now). If the page does not render well in Lynx, then the page is already broken for the many people who, for whatever reason, cannot use the more common graphical browsers. It is about time that authors realised that this actually _is_ an issue. You don't have to learn CSS to do the right thing -- just provide relevant text for the "alt" attribute. Relevant is very often going to simply be "". See also: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/alttext.txt

ok. that alt="" stuff is reasonable. but when there isn't alt text or some non- empty alt text is given, does the alt text _have_ to be displayed as normal text? i think the confusion generated by displaying it as nromal text far outweighs the benefit of complying with one specific, old version (4.00) of the HTML spec without using conditional-branching to only displays it in a box unless the page specifies HTML 4.00.

> but when there isn't alt text I'm going to be investigating that particular case soon. We may change our behaviour in the case of no alt text being specified at all. > or some non-empty alt text is given, does the alt text _have_ to be displayed > as normal text? That's the idea. The image is not available, so a textual equivalent is used instead. The reader should not even know that the image is missing. > i think the confusion generated by displaying it as normal text far > outweighs the benefit of complying with one specific, old version (4.00) of > the HTML spec without using conditional-branching to only displays it in a > box unless the page specifies HTML 4.00. Given that the benefit is that the page is readable without empty boxes and truncated descriptions everywhere, I would disagree. Again, I point you to Lynx. If the page is written with anything even remotely resembling an effort, then there should be no problems with displaying the alternative text inline. By design, that's what it's there to do. Please read http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/alttext.txt if you haven't already...

> The reader should not even know that the image is missing. (also replying to your argument #5 on http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/alttext.txt) Okay. That's one of the main points we disagree on. I think the reader should know when an image can't display because: - The page author is much more likely to notice some boxed text than inline text before she uploads her site, after she uploads it, and when she visits it. - Visitors can tell webpage authors that images are missing, and the site can be FIXED so that all of the information intended to be available is available. I hope you wouldn't say things to users of open-source software similar to you say to readers of webpages: "If it doesn't work properly, the author made a mistake. You shouldn't be informed of the problem, but instead the output should adapt to contain as much useful information as possible." The user has about as much chance of getting the problem fixed in both cases. Some users have the time and knowledge to fix an open-source software package, just as maintainers of software packages (and of websites) sometimes fix the problem quickly. How's this for a compromise? Add some prefs that let users control how mozilla handles broken images. Right clicking on a broken-image box or inline alt text would give an option to go to that area of prefs. [checkbox] show alt text while page is loading in addition to on broken images. [radio with four choices] (1) display alt text inline (preserve meaning if well-alted) (2) display alt text inline and italicize it (preserve meaning and hint at broken image) (3) display alt text in a box, giving precedence to the dimensions of the alt text. (preserve meaning and unambiguously indicate a broken image) (4) display alt text in a box, giving precedence to the dimensions of the image. (preserve layout, sometimes sacrificing ability to see whole alt text without moving the mouse) Perhaps the prefs page could show one or two examples next to each of the radioed items so they can figure out what they're going ot see.

Those are all very good ideas, and can all be easily implemented if bug 11011 is fixed. That will probably happen in the 5.1 release.

Don't you think it would hurt Netscape for a non-beta release to display a large number of webpages ambiguously (and confusingly) when they are slow, or when the user has images turned off? I'd really like to see this fixed sooner. How about making the css identifier something like "moz50only-alttext" to discourage people from using it in their own style sheets, allowing it to be changed quickly to match the CSS3 standard later?

I strongly agree (although for other reasons) that it would be great for bug 11011 to be fixed for 5.0's FCS (First Customer Ship). However, I certainly don't have the time to do it, and Netscape doesn't have the resources to throw at that particular problem. So unless you are willing to do the work (of find someone else to do it) then there is not much we can do about _that_. I still disagree, BTW, that it is _confusing_ to display alt text as it was intended. Have you ever browsed the web using Lynx? http://lynx.browser.org/

back to the bug - I am not seeing this on m16 ngihtly and win98. Can anyone see this?

Still visible on http://babelfish.altavista.digital.com/

so, what shall we do with this bug. Is this a imagelib bug perhaps?

I'll deal with it. I've got a bunch of these on my plate pending my ALT text retargetting work.

changing platform & os [pc/w2000], severity [normal], summary [problems with clear.gif and bolt.gif], adding to cc [if you have gripes, use bugzilla]. IMO if you want to check for bad links you should use composer, and one of its views should show you that the image file is not found.

Hm, reopening... Not sure why it was marked REMIND! From bug 24778, comment by Eric Krock <ekrock@netscape.com>: > Nominating nsbeta2. Supporting ALT well is important for accessibility. There > is also legal exposure for AOL under ADA for lack of accessibility. Therefore > we should try to do as well as possible for FC for both reasons. I need to spec the behaviour before all the ALT bugs can be fixed, and to do that I need some free time, and that won't happen before June 1st. So, I'll do it as a top priority on June 1st. [cc'ing Eric.]

putting on nsbeta2+ radar. Will become minus on 6/15. We won't be holding the beta for this.

Ok, since Ian hasn't responded by 06-03, I'll just summarize what I've come up with, and if Ian hasn't time to do anything more detailed he can just say `yay' or `nay' to what I've got. We need an image placeholder icon of *some* sort, for all sorts of reasons which I described in bug 23691 on 04/28. The placeholder should be the traditional shapes-on-a-page for an unloaded image, a red-cross-on-a-page for an unavailable image, and a black-crossed-circle-on-a-page for a blocked/hidden image. (Hiding images, as opposed to blocking them, is bug 10723.) However, the icon does not need to be as large (32*32) as that traditionally used in Mozilla -- 16*16 is probably large enough. The choice, then, is between an unsized placeholder (an icon with no frame) and a sized placeholder (in icon inside a sized bevelled frame, as in 4.x). An unsized placeholder would have alt text (or if there was no ALT attribute, filename *with suffix*, because we don't know what might or might not be considered a `suffix' in future filesystems) shown in-line to the right of the icon. A sized placeholder would expand to fit the alt text if it was too small. Advantages of unsized placeholder (with no frame) ------------------------------------------------- * Encourages better writing of alt text, as alt text would run directly into following content as it should. As I wrote in bug 23691, it would prevent authors from `thinking that <a href="1.html"><img alt="previous"></a><a href="3.html"><img alt="next"></a> is sufficiently distinct, when it's not (it would come out as "previousnext" in Lynx or voice browsers)'. * More consistent (between images) display of alt text if the image fails. Expanding the frame to show alt text, where necessary, could do even weirder stuff to layouts than having no frame at all would. Confining the alt text in a rectangular frame would also prevent long alt text from wrapping nicely around adjacent boxes -- especially when, one day, we do contoured text around non-rectangular objects. * More consistent (between images) display of alt text while an image is loading, for the same reasons as given above. * Better space conservation. Presumably, half the reason to hide/block images is to take back their screen real estate, as well as their bandwidth. * Helps prevent authors from making the mistake of thinking that they can rely on image dimensions for text layout purposes. * Minimum acceptable size for an image placeholder (so as to get at its context menu, or click to load it) would be about 16*16 pixels -- it should never be smaller. So for all those 1*1-pixel graphics, the placeholder won't be the same size as the image anyway; and if we used the image's size for all images except those smaller than 16 pixels in either dimension, we could give a false impression about how large those small images were. Advantages of sized placeholder (with frame) -------------------------------------------- * Better incremental display if the image loads, which it usually will. We could just use a sized placeholder during the loading, and revert to an unsized placeholder if the image fails (this is the behavior complained about in bug 40623); but that could mean a sudden reflow a couple of minutes (!) after everything else on the page had completed, when Mozilla gave up on getting any response from the image's server. That would be unacceptable. Or we could give the image /n/ seconds to show itself in the sized frame, and then revert to an unsized frame until/unless the image started to load; but that would probably be too messy and force lots of jumpy reflows when an image took a bit longer than /n/ seconds to start loading. * Scrooge scenario: I load a page without images, and see all their sized frames. I use the context menu to hide/block those images which, based on their size, look Unlikely To Be Useful, and then click the Images button. This scenario only works if the frame is sized in the first place. * Better visual structure, particularly for consistency across a range of pages where a graphic in a consistent position on those pages is loaded on some cases but not loaded (for whatever reason) in others. * Better visual differentiation between an unloaded image and a blocked/hidden image. So they both have their advantages, but my pick of the best choice for the Web as a whole is for the placeholder with no frame. Standard NISBAP disclaimer (`No, It Shouldn't Be A Pref') applies because this is far too obscure for a pref to provide any value. ... Ian?

Thanks for the summary Matthew, I'm now working on my recommended spec.

Ok, here is my first proposal for the final ALT text implementation's specification. I would appreciate any comments so that we can iron out any flaws before we pass this on to the programmers. Image Settings -------------- Legacy browsers have offered two options: to download images, or not to download images. This proposal suggests the following three modes: Always Load Images Always downloads and displays images used on web pages, if the images are available. Load Images On Demand Does not download images used on web pages, but reserves some space for them. Click on images to download them. Don't Load Images Does not download images and does not reserve room for them. You can still cause important images to be displayed by right-clicking on their icon and selecting "Show Image". For first release, the second mode can be forgotten if that is too much work. Thus we are left with the first and last modes, as we already have planned. There should also be a preference, just like in Lynx, to deal with badly designed pages: [ ] Show icons for _all_ images. See below for a description of the _implementation_ of this preference. Extra time needed: time required to add to the prefs UI, add a new pref to the preference system, and make Layout aware of the setting. Alt Texts --------- If the IMG or INPUT element has an "alt" attribute, then the contents of that attribute should be used as the alternate text. Failing that, if either the "height" or "width" attributes equal either "0" or "1", then the alternate text should be taken to be the empty string, "". Otherwise, the alternate text should be the contents of the first of the following attributes that is present on the IMG or INPUT element: title name id Experience has shown that the filename is considerably less useful than would be first thought, and therefore we should ignore it when inventing the alternate text. In Mozilla, this has to be implemented in the function called GetAlternateTextFor. http://lxr.mozilla.org/seamonkey/search?string=GetAlternateTextFor Estimated time for implementation: 2 hours. Should be relatively easy for a contributor not very familiar with the code to write. Icons ----- Alternative text will be prefixed by an icon (as described below). The icon is chosen from the following list: For images that have not been downloaded, use a generic image or object icon. For images that are known to be broken, use the broken image or broken object icon. In future releases this proposal will introduce: For images that have been blocked, a blocked image icon. For images that are in a format not supported by Mozilla, an unknown format icon. In the next section, when referring to "an icon", the icon should be chosen from the list above. Placeholders ------------ If an image cannot or will not be shown, then: For images that have not been downloaded but are about to be, in "Always Load Images" (and "Load Images On Demand") mode(s): If the "height" and "width" attributes are given, create a borderless box with the height and width given (interpret the height and width attributes as pixel lengths). If there is any alternative text, or if the "show icons for all images" pref is enabled, then insert an image icon inside the placeholder. If there is any alternative text, then insert it after the image icon in the placeholder frame. If the frame is too small for the icon and/or the alternative text then they will be clipped, just like with the CSS declaration "overflow:hidden". However, if the "show icons for all images" option is selected, then the frame should be enlarged so that the image icon is visible. For ALL other cases (blocked images, images not downloaded in "Don't Load Images" mode, broken images, and unrecognised images): Replace the IMG or INPUT frame with an empty inline element. If there is any alternative text, or if the "show icons for all images" pref is enabled, then insert a text frame containing an image icon inside the IMG or INPUT element. If there is any alternative text, then insert it after the image icon in the text frame. These IMG and INPUT frames should be treated just like any other frame as far as style resolution is concerned. Note that broken and blocked images never take up their size as given in HTML, and if they are unimportant according to the author (i.e., alt="") then they will in fact not be shown at all, unless the "show icons for all images" pref is selected. The image-followed-by-alternative-text is equivalent to the pseudo-CSS3: "content: url(icon) alternative-text;". This is why I say the image icon should go in the _text_frame_ (internally it very probably does not in fact). The icons should be relatively small so as not to disrupt most text but be easily clickable, for instance 16 pixels by 16 pixels square. There should never be a sized placeholder frame for an image where we do not know the size. Given that, here are some replies to Matthew's comments (which I largely agree with): > * Minimum acceptable size for an image placeholder (so as to get at > its context menu, or click to load it) would be about 16*16 pixels > -- it should never be smaller. So for all those 1*1-pixel graphics, > the placeholder won't be the same size as the image anyway; and if > we used the image's size for all images except those smaller than 16 > pixels in either dimension, we could give a false impression about > how large those small images were. I don't know that we actually _want_ the user to be able to get to those particular images in the first place... have you thought of the mess some pages would turn into, if every 1x1 transparent pixel GIF turned into a 16x16 icon??? > * Better incremental display if the image loads, which it usually > will. We could just use a sized placeholder during the loading, and > revert to an unsized placeholder if the image fails (this is the > behavior complained about in bug 40623); but that could mean a > sudden reflow a couple of minutes (!) after everything else on the > page had completed, when Mozilla gave up on getting any response > from the image's server. We have that problem anyway with going in the other direction. However we do it, there is no way we can reliably get the placeholder frame the right size initially without the "height" and "width" attributes being known to us. Might as well go for the solution which gives the least difference each time. (Sized if we know the size in advance, inline if we don't.) > * Scrooge scenario: I load a page without images, and see all their > sized frames. I use the context menu to hide/block those images > which, based on their size, look Unlikely To Be Useful, and then > click the Images button. This scenario only works if the frame is > sized in the first place. Hopefully my "Load Images On Demand" mode allows this while still leaving the option of disabling images completely.

BTW, this should _not_ be that difficult to implement. 1 or 2 days, spread over a week or so, should be enough by my own very rough estimation. (I say spread over a week because it will need QA feedback.)

Reassigning to default component owner. The spec now exists, see above. Matthew, please tell me what you think of it as soon as possible...

Programmers: go with this, hurry, implement it, we're running out of time for nsbeta2. The only *major* objection I have to it is a subtraction, not an addition, and subtraction will (I assume) be much easier to do later than addition will. Having said that, Ian, here are my objections ... * I think offering three modes is a large mistake, because it will have an *extremely* low usefulness-to-confusion ratio. As far as image layout is concerned (not to be confused with image loading, e.g. blocking), users only care about `images off' and `images on'. I can't imagine anyone -- apart from Web weenies such as yourself, Alan J Flavell, and (possibly) Tim Berners-Lee -- being interested in more fine-grained control than that. Whether the pref is set to sized (`Load Images on Demand') or unsized (`Don't Load Images') frames, it's going to produce undesirable results on some pages. We know that. The choice your pref offers (and the choice I was trying to make earlier), is whether pages designed around the HTML specs stuff up, or whether pages designed around legacy browsers stuff up. But if providing a pref (as opposed to just choosing a behavior and running with it) is to be worth it, the following series of steps has to regularly happen: * user sees undesirable layout on a page * user knows that layout on pages can be affected by this pref * user recognizes that changing the pref will help with the layout on this page (a non-trivial cognitive task in itself) * user has enough motivation to change the pref (rather than just coping with the odd layout, or going to another page) * user opens the pref dialog, opens the relevant category, opens the relevant subcategory, finds the pref, and changes it * user changes pref back to its original setting after leaving page/sub-site/ /site. And I really don't think that's going to happen, not even if the pref is put in a highly prominent place in the prefs dialog, with bucketloads of explanatory text and bright flashing colors. An indication of how useless such a pref would be can be gleaned from your difficulty in giving the options appropriate names: `Load Images On Demand' and `Don't Load Images' implies that in `Don't Load Images' mode you can't load images at all, which is not the case. The simplest accurate and understandable labels I could think of would be `Don't load images, but leave space for them on the page' and `Don't load images, just show them as an icon', but even that is still pretty gobbledygooky. * I can see the point of `Show icons for _all_ images' in Lynx, but I can't see the point of it in Mozilla. In Mozilla showing icons for all unloaded images is an order of magnitude more important than it is in Lynx, because Mozilla can't get away with assuming that all you want to do with images is show their alt text (and occasionally open them in an external viewer). * Having a special ALT case for images measuring 0 or 1 in one dimension is only useful, under your spec, if those same images also happen to have a TITLE, NAME, or ID value (in which case those attributes would be ignored instead of used). But it's hardly likely that any of these attributes will be present for such graphics anyway, is it? Why would I, as a page author, want to give a TITLE to a graphic that was practically impossible to hover over anyway? And why would I want to manipulate a pixel graphic with JavaScript? * In deriving alt text from non-ALT attributes, I think ID should come before NAME, rather than the other way around, because ID is the standard element attribute -- I assume NAME will be deprecated eventually. (Yeah I know, it's a trivial point, given that images are unlikely to have both attributes set simultaneously ...) * The reason I said images smaller than 16*16 should still have a 16*16 icon was because they fall into the class of images which are Unlikely To Be Useful, so the user would often want to get at their icon to block them or hide them. But on thinking about it some more, I guess these images are more likely to be blocked with a generic rule (based on image dimensions) than on a case-by-case basis, so I was wrong there. I guess I wouldn't want a blocked 1*1 image being even more annoying (because it had a 16*16 icon) than an unblocked one. * I still think that image frames should be unsized until they start loading, even if we know their WIDTH and HEIGHT; because it is far more acceptable for layout to jump around five seconds after the page begins loading (when the image starts loading and we give it a sized frame), than it is for the layout to stabilize after ten seconds but then jump around two minutes after the page begins loading (when the image server times out and we turn its sized frame into in-line alt text).

> ... because Mozilla can't get away with assuming that all you want to do with > images is show their alt text (and occasionally open them in an external > viewer). right on. > I still think that image frames should be unsized until they start loading, > even if we know their WIDTH and HEIGHT; because it is far more acceptable for > layout to jump around five seconds after the page begins loading (when the > image starts loading and we give it a sized frame), than it is for the layout > to stabilize after ten seconds but then jump around two minutes after the page > begins loading (when the image server times out and we turn its sized frame > into in-line alt text). I disagree with this point on grounds that images working is much more common than images not working, which is in turn more common than images timing out. Also, layout would be likely to jump several times as the images load (assuming unsized image frames), but it should only jump once when they time out (assuming sized image frames).

Jesse, I think most of your disagreement would disappear if the suggestion I made in bug 17325 (on 1999-11-19) was implemented. But I could be persuaded otherwise.

> I think offering three modes is a large mistake, because it will > have an *extremely* low usefulness-to-confusion ratio. Agreed. I was `forced' into suggesting this pref because of a conflict between your previous statements and my own views. Since your views have basically changed (see below), this can be removed altogether. > `Don't Load Images' [...] The choice your pref offers [...] is > whether pages designed around the HTML specs stuff up, or whether > pages designed around legacy browsers stuff up. It was actually included so that you could use your "Scrooge scenario": loading a page without images, and then, based on all their sized frames, using the context menu to hide/block those images which look Unlikely To Be Useful. If that is not a high priority, then I am happy to remove the possibility of doing this since it simplifies everything. > `Show icons for _all_ images' [...] In Mozilla showing icons for all > unloaded images is an order of magnitude more important than it is > in Lynx, [...]. This is why I had three prefs: 1. You want images (graphical browser), 2. You want images, but only when you ask for them, 3. You don't want the images at all (text browser). There is no way we can have "show icons for all images" enabled by default (and the only option) -- that would make pages literally unreadable. If you don't believe me, try browsing the web with the following in your html.css file: img[width="1"] { padding: 0.5em !important; border: solid red !important; } img[width="2"] { padding: 0.5em !important; border: solid red !important; } img[width="3"] { padding: 0.5em !important; border: solid red !important; } img[width="4"] { padding: 0.5em !important; border: solid red !important; } img[width="5"] { padding: 0.5em !important; border: solid red !important; } img[height="1"] { padding: 0.5em !important; border: solid red !important; } img[height="2"] { padding: 0.5em !important; border: solid red !important; } img[height="3"] { padding: 0.5em !important; border: solid red !important; } img[height="4"] { padding: 0.5em !important; border: solid red !important; } img[height="5"] { padding: 0.5em !important; border: solid red !important; } Try, for example, some of the following: http://home.netscape.com/ http://www.microsoft.com/ http://www.hp.com/ http://www.ibm.com/ http://www.bbc.com/ It is extremely nasty. Now, instead of the above lines, insert the following: img[width="1"] { display: none !important; } img[width="2"] { display: none !important; } img[width="3"] { display: none !important; } img[width="4"] { display: none !important; } img[width="5"] { display: none !important; } img[height="1"] { display: none !important; } img[height="2"] { display: none !important; } img[height="3"] { display: none !important; } img[height="4"] { display: none !important; } img[height="5"] { display: none !important; } ...and try those sites again. (Note that the above is only a rough approximation of what it would really feel like, so don't draw too many conclusions from this.) > Having a special ALT case for images measuring 0 or 1 [should be removed]. Agreed. That was a relic of my spec at a time where I was still thinking of using the filename to generate the alternate text. > In deriving alt text from non-ALT attributes, I think ID should come > before NAME, Ok. > I still think that image frames should be unsized until they start > loading, even if we know their WIDTH and HEIGHT [...]. As David R said, working images are a _lot_ more common than those that time out. Your way, the page is *guaranteed* to be reflowed. If we size as much as possible while loading, then only broken and unsized images will reflow. In fact, doing it this way will encourage good authoring practice: if authors include height and width on all their images and make sure they have no broken images, we will have no reflows whatsoever! Updated spec coming up...

New spec for perusal -- please criticise ASAP: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/altspec.txt

> There is no way we can have "show icons for all images" enabled by default (and > the only option) -- that would make pages literally unreadable. No it wouldn't. Not if, as you suggested in your spec, and as I (eventually) agreed, the icons were clipped if the image was less than 16 pixels in either direction. > If you don't > believe me, try browsing the web with the following in your html.css file: I can't -- see bug 36928. :-/ > As David R said, working images are a _lot_ more common than those that time > out. Your way, the page is *guaranteed* to be reflowed. If we size as much as > possible while loading, then only broken and unsized images will reflow. In > fact, doing it this way will encourage good authoring practice: if authors > include height and width on all their images and make sure they have no broken > images, we will have no reflows whatsoever! Broken images are often not the fault of the author at all: they may be the result of server overload (e.g. the Slashdot Effect), unscheduled downtime for an external image server, or whatever. And I still don't like the idea of a page reflowing minutes after I've loaded it. A way around this would be to assume that `well, the user wasn't expecting to get the alt text for this image anyway', and do a refined legacy-browser-like display of alt text (effectively showing it in a scrollable IFRAME in the sized image frame) for broken/timed-out images. But I suspect you'd grate your teeth at the extent to which this broke the HTML spec's original intent for ALT text; and since I can't think of a better solution, I guess you can have it your way. :-)

>> There is no way we can have "show icons for all images" enabled by >> default (and the only option) -- that would make pages literally >> unreadable. > No it wouldn't. Not if, as you suggested in your spec, and as I > (eventually) agreed, the icons were clipped if the image was less > than 16 pixels in either direction. According to my spec, that is what will happen when "show icons for all images" is _disabled_. When it is enabled, I am proposing that icons be NOT clipped. That's ok, right? Regarding the case of pages reflowing "minutes" after the original load: 1. Images timing out is orders of magnitude less likely than images being found in good health. 2. A couple of reflows two minutes after initial load on the occasional page is a lot less annoying than a reflow on almost every page, three seconds after initial load. 3. Your refined idea thingy is inconsistent with what would happen if the image was found to be broken straight away, rather than several minutes later, and may therefore confuse users even more than a reflow. My standard IANAUW disclaimer applies (I Am Not A Usability Weenie). :-)

*** Bug 41658 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 41924 ***

Marking Verified as a dup.