656479 - Markup counter is incorrect

Status: VERIFIED WONTFIX

(Websites Graveyard :: markup.mozilla.org, defect, P1)

Description

[krupa raj[:krupa]]

Attachment: screenshot

Firefox 4.0.1

steps to reproduce:
1. Load https://markup.mozilla.org/en-US/#/linear/54uQ?playback=true&be_grateful=true
2. Notice the markup counter

expected behavior:
Counter says 'Mark 7 of 7 for an open Web.'

actual behavior:
Counter says 'Mark 7 of 6 for an open Web.'

Staging seems to be fine, though.

Comment 2

[Adam Miller]

The counter is not perfect and wasn't built to be. It was built to be the best approximation of a marks position in the line without having that position change overtime, even as marks are added/removed and the line size changes.

The mark's position is just it's primary key, and the max number of marks is the highest primary key currently in the marks table. 

What's likely happening here is that the very last mark in the database (number 7) was flagged, but not deleted, and so it's accurately reporting that there have been 7 marks made, even though you cant see them all. 

We want that permanence – we always want the 6th mark to be labeled as the 6th mark, even if the 5th mark was a exquisite rendering of a penis that got deleted – so that's why we have the solution we have now. If we need to reevaluate how we calculate those numbers to handle this edge case, feel free to reopen.

Comment 3

[Austin King [:ozten]]

(In reply to comment #2)
If the counter is known to be approximate, then a hardcoded rules should fudge the counter or index so that it's always a sane value.

Psuedo code:

if current > max:
    current = max

Comment 4

[Adam Miller]

It will always be a sane value and will never be less than any of the marks positions, ie we'd never have a counter say "Mark 200 of 190", because the total is the max of the ID column in the marks table. 

Quite sure the original case would also never occur since changes brez made this week to the init_viz_data method in requests.py

The code that grabs this data is here: 

https://github.com/mozilla/markup/blob/master/ffdemo/markup/requests.py#L90-95

So again, I use that max_id variable as the upper bound, and the current marks ID as it's position within the bound. If this is insufficient, please explain how so I can get it corrected. Otherwise please close.

Comment 5

[Austin King [:ozten]]

(In reply to comment #4)
Sorry for re-opening, I wasn't aware of these details. Closing.

Comment 6

[Matt Brubeck (:mbrubeck)]

(In reply to comment #4)
> It will always be a sane value and will never be less than any of the marks
> positions, ie we'd never have a counter say "Mark 200 of 190", because the
> total is the max of the ID column in the marks table. 

The page said "Mark 22 of 16 for an open Web" when I loaded it (see duplicate bug 656671).  Is that a bug that has been fixed?

Comment 7

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #6)
> (In reply to comment #4)
> > It will always be a sane value and will never be less than any of the marks
> > positions, ie we'd never have a counter say "Mark 200 of 190", because the
> > total is the max of the ID column in the marks table. 
> 
> The page said "Mark 22 of 16 for an open Web" when I loaded it (see
> duplicate bug 656671).  Is that a bug that has been fixed?

It does indeed seem fixed; the lines brez points to in comment 4 were added by Fred, here: https://github.com/mozilla/markup/commit/a9c3839fcd4109667e5d78408ed024a808338918, on the 17th, which is after you filed.

Let us know if you can still reproduce the issue, Matt.  Thanks!

Comment 8

[Fred Wenzel [:wenzel]]

Yes, this should indeed be fixed. As comment 4 indicates, the max counter used the actual number of marks before, while the positional counter always used the current mark's ID. Now both use the id, so "mark 200 of 190" is now impossible. Note that if you delete ten (or 1000!) out of the middle, the counter will still, technically, be off by that much, but at least it won't be grossly inconsistent.