locked
Calendars in chrome cause page refresh which casues the page the calendar is on to scroll back up to the top of the page RRS feed

  • Question

  • Using chrome, changing a calendar date on an edit form, refreshes the page and ends up scrolling it up to the top. This does not happen in firefox or IE10. The page stays put when you change a date in the calendar. In chrome, the page refreshes and scrolls up to the top, which is annoying my users.

    Anyone seen this? any fix? didn't happen in sharepoint 2010.

    Friday, November 8, 2013 7:10 PM

All replies

  • I see it as well.  There were a lot of changes between 2010 and 2013, especially regarding the use of JavaScript for these controls.


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Friday, November 8, 2013 9:12 PM
  • please do not mark as solved, saying "oh welp there are a lot of changes and some stuff broke" is not a solution.

    what is the obsession with people marking unsolved things as solved. it just pisses people off.

    Monday, November 18, 2013 4:29 PM
  • It is done when there is no response from the original poster after a period of time.  If you need to investigate a fix for this particular issue, your best bet is to open a Microsoft PSS case.

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Monday, November 18, 2013 5:23 PM
  • I would imagine that costs money, and does not help anyone else with the same problem. So not an option.

    I will post back when I find a solution, or others can. That is the point of web forums, maybe it takes a year to solve a case, but at least there is some record for others. Moderating things incorrectly to artificially increase a "completed work orders" count is not the way forums should be run.

    Monday, November 18, 2013 5:37 PM
  • PSS cases do cost money, except in the case of a security issue or a confirmed bug.  Given this is easily repeatable, it likely falls under the bug status. 

    As for moderation, the moderator was following the guidelines outlined by those who own the forum.


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Monday, November 18, 2013 5:39 PM
  • Did you want any more help with this issue or were you able to open a PSS case to file a bug?

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Sunday, December 1, 2013 5:24 PM
  • This is a side effect of a basic design flaw in Chrome that causes some JavaScript events to misfire and/or get ignored due to how it handles lazy loaded JavaScript. Not a Microsoft bug. Similar issue is what used to cause Chrome to not display a scrollbar in SharePoint 2010. This is by design, by Google. Even other WebKit browsers like Safari are not impacted. The only fix for everyone is if someone can pressure Google to accept the fix that was submitted by SourceForge back in late 2009 (they also ran in to this same root issue). If there is interest I'll try and dig up the bug and submitted fix from the Chromium project, it was closed as intended and by design.

    You can workaround this though via some browser detection. So that inline editing is disabled under chrome.


    My CodePlex - My Blog - My Twitter
    Join me at the San Francisco SharePoint User Group!

    If this post helped you or answered your question please remember to mark it! :)

    Monday, December 2, 2013 12:03 AM
  • Google is only slightly more disinterested in my opinions than ms is, so I doubt they will do anything about this bug.

    I am not surprised that its google's fault here, as it seems like another one of their "features" that they will never fix. The reason why we use chrome is 1) adblock 2) GPO and AD integration and 3) perception that it is more secure than IE. Trust me, I would prefer to use firefox, however mozilla needs to get its ass in gear with supporting group policy.

    That said, I would never be filing any bug reports with MS. The last time I tried, they wanted to charge my credit card $300 and then credit me back if *they* determined that it was their fault. No thanks! I grant you that the system may have changed, but I view it in a similarly arcane and magical way as I would view requesting an audience with the pope. Its just not something normal people do. They have trained people for 20 years not to call microsoft, so I am not about to start now over a stupid calendar bug.

    I would be interested in a work around that I, as a non programmer, could implement on the site to prevent this behaviour. I do appreciate the technical explanation, so thanks for that.

    Monday, December 2, 2013 5:40 PM
  • I would also like to know of a workaround for this issue.

    I see MaartenSundman suggested disabling inline editing. Can someone elaborate?
    (This is apparently not the same as turning off the "Quick Edit" for a list)

    Monday, September 8, 2014 6:18 PM