Mark as read not working on Safari [#1353260]

Being logged as Wolfflow at http://commons.acquia.com/mycontent using Safari on Mac OSX
the "Mark as read" does not work.

Comment	File	Size	Author
#3	markasread1.jpg	131.61 KB	Wolfflow
#3	markasread2.jpg	149.33 KB	Wolfflow
	mark_as_read.png	19.62 KB	Wolfflow

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Wolfflow CreditAttribution: Wolfflow commented 26 November 2011 at 12:01

The ajax select box "Mark as read" does not work even in Firefox and Chrome, though!

Comment #2

ezra-g CreditAttribution: ezra-g commented 29 November 2011 at 14:29

Status:

Active

» Postponed (maintainer needs more info)

The button functions normall for me on Chrome on Mac OS 10.7.

Could you elaborate on "Doesn't work" ?

Comment #3

Wolfflow CreditAttribution: Wolfflow commented 1 December 2011 at 11:48

File	Size
markasread2.jpg	149.33 KB
markasread1.jpg	131.61 KB

Again with support of pictures and on MAC OS X Lion and Safari Version 5.1.1 (7534.51.22)

1 I login in http://commons.acquia.com/mycontent
2.Mark 3 Items (see attached "marasread1.jpg ) for being marked as read.
3. Clicked on button "Mark as Read"
4. Results (see attached "markasread2.jpg") the 3 discussion Items are listed again.

That's it

Comment #4

deltalat CreditAttribution: deltalat commented 21 December 2011 at 00:45

I have the same issue using Chrome on windows.

After clicking on the "Mark as Read" button, the screen will display all articles. I believe this issue showed up after the last views update (could be wrong on that). I have verified that the "Mark as Read" button works correctly by looking at the history.timestamp field before and after clicking the button for a particular node.

The problem is more than likely in the view. The view that generates this page is og_my_content->Unread content

If you look at the sql query there is a line that reads:
LEFT JOIN history history_user ON node.nid = history_user.nid AND history_user.uid = 0

I think it should be equal to the the uid of the requesting user. If set to zero, history_user.timestamp is set to null so every field is returned.

I saw a similar error in another view and was able to work around it but that work around does not work here.

Comment #5

mstef CreditAttribution: mstef commented 21 December 2011 at 14:51

If you look at the sql query there is a line that reads:
LEFT JOIN history history_user ON node.nid = history_user.nid AND history_user.uid = 0

I don't know how a different browser/OS could cause the query to change. I also don't know where you're seeing that query. The query, indeed, works fine, and uses the current UID - there's no doubt in my mind about that.

Cannot reproduce with Linux or WinXP with any browser.