Description

FeatureRequests/AutoScrollingTheEditorTextArea presently has over 100 duplicate ID warnings similar to: line 175 column 5160 - Warning: <span> anchor "line-1" already defined.

The duplicate IDs may adversely effect the auto-scroll the text editor area feature -- double-clicking on an effected line number will scroll the text editor to the wrong place.

Steps to reproduce

View the source of FeatureRequests/AutoScrollingTheEditorTextArea, MoinMoinBugs/DuplicateIdsOnSpanTags/Test, or MoinMoinBugs/DoubleClickJSWithVeryLargeTables with Firefox HTML Validator add-on.

The duplicate ID warnings frequently appears on pages with pre-formated data (enclosed by {{{   }}}) and possibly other types of preformatted text.

The duplicate ID warnings appear only when a cached version of a page is used (e.g does not happen in page preview, after a page is saved, or when page caching is turned off).

Example

This is the raw wiki text used in the screenshots below. 

=== Duplicate ID Warning Messages ===
Paragraph 1.
{{{
aaa
bbb
ccc
}}}
Paragraph 2.
{{{
ddd
eee
fff
ggg
hhh
iii
}}}

To create these screenshots, the autoscroll javascript was modified. All span tags that look similar to <span class="anchor" id="line-3"></span> are made visible by setting the innerHTML equal to the ID and colored red.

Viewing the sample wiki page in edit preview or with page caching turned off yields the following.

preview.png

When the page is saved, all the IDs change, but no duplicate IDs are present.

saved.png

After the saved message is cleared or the page is subsequently loaded from cache, duplicate IDs are present. Here line-1 through line-6 are duplicated.

aftermsgcleared.png

If we could make the span IDs from cached pages look like the IDs in page preview (or page caching off), then this one line fix to parser/text.py will enable the auto-scroll feature to scroll to the target line within text enclosed in triple curly braces. When a cached version of a page is used, it misses the target line. 

diff -r 203afc609f8a MoinMoin/parser/text.py
--- a/MoinMoin/parser/text.py   Mon May 24 10:43:08 2010 +0200
+++ b/MoinMoin/parser/text.py   Mon May 31 17:18:47 2010 -0700
@@ -49,6 +49,6 @@
 
             self.lineno += 1
             self.request.write(formatter.line_anchordef(self.lineno))
-            self.request.write(formatter.text(line))
+            self.request.write('<span>' + formatter.text(line) + '</span>')
 
         self.request.write(formatter.preformatted(0))

Component selection

Details

When I copy the entire MoinMoinBugs/DoubleClickJSWithVeryLargeTables page to my 1.9.2 test system, the duplicate ID errors are not present (because I had caching turned off). When I copy the the page to my copy of the hg repository, the errors are present.

The problem appears to be a bug introduced in the 5611 to 5614 changeset. When I use the TortoiseHG Repository Explorer to revert the 1.9.3-pre changes one at a time, the warning messages go away when I revert 5611. However, the warning messages do not reappear after I use the update function to reapply 5611. The warning messages reappear when I update to the 5614 changeset.

I guess you have to redo this check, your results are unclear and it is rather sure to assume that ad60b3570553 and cc15366f7b74 are completely unrelated to id generation. Maybe you were fooled by some caching effect (cached bytecode of page rendering, see action menu to clean cache) or did not restart moin on the new code?

Yes, I was fooled by some caching effect or some other thing. Unfortunately, I am in the same state. But I think I found a workaround -- adding caching_formats = [] to wikiconfig.py seems to eliminate the duplicate ID warning messages.

This problem has the feel of a threading or timing issue. As I use TortoiseHG Repository Explorer to back off changes, restart the wiki server, and reload the page, then sometimes the first page reload has no duplicate ID warnings, but a second reload will have warnings. Eventually, I find a point where I consistently have no warning messagess even after 10 or so page reloads. As I reverse direction and reapply changes, the warning free zen state continues even into the changesets that produced duplicate ID warnings a few minutes ago.

Other possible clues are that I have never seen the duplicate ID warning messages after doing a page save or edit preview. But the warning messages do appear after an edit cancel. Also, once the warning messages appear on a page, I don't recall an instance where a simple page reload resulted in no warning messages. However, deleting a bunch of moin pyo/pyc files and then doing a page reload yields no warning messages.

The above is wrong again. The problem now appears to be that the line IDs within the <span class="anchor" id="line-nn"> of the cached version of the page are always incorrect. Deleting the cached page results in a page free of duplicate ID warnings. Reloading the page (making use of the page cache) results in duplicate ID warning messages. Preformated text enclosed in triple curley braces have embedded span tags in the cache. The IDs should always of the form "line-nn-m" where m is the sequence number of the block of preformatted text.

Wrong again. The line numbers within the cached version of the page are numbered as intended. There appear to be some variables attached to the formatter object to avoid line number collisions in preformatted code. When there are multible sections of preformatted code, the second line-1 becomes line-1-1 and the third line-1 becomes line-1-2. These variables are not saved to cache, so when a cached page is loaded the non-pre-formatted lines are numbered with values that sometimes collide with the preformatted code.

Need to revisit the autoscroll javascript - at minimum some of the comments are wrong.

I could use some help. As this is being rewritten in 2.0, I don't want to expend an lot of effort in understanding parsers/formatters nor fixing them. Assuming this last scenario is correct, I am hoping to fool the preformatted parsers/formatters into thinking all the span ID numbers from line-1 to line-999999 have already been used, so they are forced to use line IDs like line-1-5 to line-??-5 and above. A pointer to the code that generates span IDs like line-1-1 or the magic numbers to change on the formatter object would be helpful.

Now I am not sure if the line IDs are numbered as intended or not. I now understand the source of my confusion and concern as:

I have not been able to recreate a case where autoscroll misses the intended target because of a duplicate line ID.

Enhancing autoscroll to hit a target line within triple curly braces requires a more stable line ID scheme, preferably the one used in edit preview.

Workaround

Add this to wikiconfig.py: 

    caching_formats = []

Discussion

Plan

CategoryMoinMoinBug

MoinMoin: MoinMoinBugs/DuplicateIdsOnSpanTags (last edited 2010-06-01 22:09:59 by RogerHaase)