If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Markup "View Last" option doesn't actually jump to the last mark

VERIFIED WONTFIX

Status

Websites
markup.mozilla.org
P3
normal
VERIFIED WONTFIX
6 years ago
6 years ago

People

(Reporter: dholbert, Assigned: Adam Miller)

Tracking

unspecified
x86_64
Linux

Details

(URL)

(Reporter)

Description

6 years ago
Each time I've gone to Markup this morning and hit "View Last" (3 times), it hasn't taken me to the last mark.  Rather, it takes me to a mark that's maybe 5 or 6 from the end.

This seems like a bug.

(At first I assumed it was taking me to whichever mark was last *at the point where I loaded the page*, but that's not the case -- I reloaded & no new marks had been added, and yet "View Last" still took me to the same mark, 5 or 6 from the end.)
Assignee: nobody → jbresnik
Blocks: 628811
Target Milestone: --- → 1.1

Updated

6 years ago
Assignee: jbresnik → adam
(Assignee)

Comment 1

6 years ago
Here's what I believe is happening. 

When the visualization is initialized, references to the first and last mark and the max id is loaded into the app and used throughout the users interaction with the app. If other users add a marks after the initialization, then the last mark and max id values are invalidated, and things will start behaving like this. 

It also seems that init_viz_data is being cached. Is that possible? Is there anywhere that could be getting stuck? 

I'm going to start working on fixing the first problem. The fact that it gets stuck in this state though, I can only think would be the fault of caching.
(Reporter)

Comment 2

6 years ago
(In reply to comment #1)
> When the visualization is initialized, references to the first and last mark
> and the max id is loaded into the app and used throughout the users
> interaction with the app

(I'm not sure that that's the case - as noted in comment 0, I tried reloading (and shift-reloading), and 'view last' still takes me to the exact same mark, 56 or 6 from the end.  So unless Markup caches data on the user's machine in a way that shift-reload doesn't clear it, I don't think the stale last-mark-ID could be coming from the user's machine.)
(Assignee)

Comment 3

6 years ago
Right, I know, I saw the same BUT I was just questing if there could be anything caching init_viz_data on the server side. Varnish? MySQL query cache? I don't know whats in use on the production server, but it sure seems like something is sending stale data. 

 Either way I dont think this will be so much of an issue after I get my fix committed.
Priority: -- → P3
Target Milestone: 1.1 → 1.2
Yes, it's most likely caching. init_viz_data is a regular URL, so it'll be cached by the frontend proxy for a while[tm].
(Assignee)

Comment 5

6 years ago
I added code to address this here: 
https://github.com/mozilla/markup/commit/df865ca2a35faab1bd9d1725d35295315b7cfad3

I changed the visualization to do a check for a higher id number every time new marks are loaded. If the data it got from init_viz_data is stale, and it loads a mark with a higher id, it will update the max mark number in the mark information box ( "Mark x of y for an Open Web" ) and will update the "View Last" button to link to this new mark. 

Not a perfect solution, but probably the best I can do if init_viz_data is getting cached. We could look at lowering the expiration time on init_viz_data, or maybe expiring it after every 5th mark is submitted? 

I'll leave this open for now in case we want to do something about the cache.
Are you sure this patch is actually for this issue? There's all sorts of stuff in there that seems to have nothing to do with the issue at hand.

If you have several changes in the same file that are unrelated, you can use `git add -p` to select ("stage") only parts of the patch for committing.

Also, thanks for fixing this, but keep in mind, bugs for the milestone 1.1 should get precedence over 1.2.
(Assignee)

Comment 7

6 years ago
Sorry for not separating them out, but yes I'm sure of what I committed. 

The changes to markApp.linear.js fix a lot of annoying issues, and I'd appreciate if it could be reviewed and pushed to production asap. 

l've added line comments to the markApp.linear.js diff on github to make it easy for you to see why I made the changes I made. 

https://github.com/mozilla/markup/commit/df865ca2a35faab1bd9d1725d35295315b7cfad3
Makes sense. Thanks for the comments, they look good.

Matt, can you take a look at these bugs on dev? I think you can imitate the behavior in comment 0 by opening one browser in markup's browse view, then use another browser to add a few marks. When you click "last mark" in the first browser, it should take you to a mark that's clearly not the last.

That should be reproducible on stage.

With Adam's fix (on dev), this should be gone.
Target Milestone: 1.2 → 1.1
Bumping to resolved/fixed per comment 7 and comment 8. I'll begin QAing this. Thanks adam & wenzel for the patch.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: 1.1 → 1.2
Hmmm ... I'm still seeing the same behavior as in comment 0 on dev (markup-dev.allizom.org).

Steps to reproduce: comment #8)
> you can imitate the behavior in comment 0 by opening one browser in markup's
> browse view, then use another browser to add a few marks. When you click
> "last mark" in the first browser, it should take you to a mark that's clearly 
> not the last.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
MarkUp has run and is EOLed.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → WONTFIX
(In reply to Fred Wenzel [:wenzel] from comment #11)
> MarkUp has run and is EOLed.
Yes ... we are end-of-life. The sand in the hour glass has sifted to the bottom.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.