Last modified: 2012-04-19 21:43:42 UTC
Created attachment 6734 [details] Screen print of the error Reporting against Babaco Release : r58199 Steps to Reproduce :: 1) Select a random page 2) Edit page 3) Create headings 4) Select heading text and change a heading level Level 3 to level 4 <<A new heading is created of level 7>> 5) Undo changes 6) Select heading text and change a heading level Level 3 to level 4 <<A new heading is created of level 6 and the navigation TOC also display the invalid>> <<Level 1 and Level 3 has come to one level in the navigation TOC>> Expected Outcome:: All the invalid levels should not display in Navigation TOC If the text is selected, it should either validate whether the text is of header type or ignor the text convert to headers Test Environment:: Browser (User-Agent): Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.27 Safari/532.0 Browser (User-Agent): Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 (.NET CLR 3.5.30729) Browser (User-Agent): Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
This bug is two-fold: first, there's the issue that if you select just the header text instead of the entire header, changing the header level doesn't work the way you expect. We could maybe look at the whole line instead of just the selection, I'll discuss this. Second, there's the issue of the following text: == Foo == ====== Bar ====== ==== Foo ==== ===== Bar ===== displaying both "Foo"s at the same indentation level, as well as both "Bar"s. This is not a bug: if you click Show preview, that's exactly what the table of contents in the article will look like, we're just mimicking that. The individual headers in this case are not invalid; the one in the first test case was, because it was a level 7 header (valid header levels are 1-6).
Closing the bug as per comment 1
