Bug 382587

@Laurent this also happens with KMail.

I did some debugging and found that the scroll position is remembered by the chromium backend used by Qt. The scroll position restore used by akregator/messagelib isn't working because javascript is disabled. As enabling javascript might have side effects, a possible solution is loading a blank page before a new article is loaded in the viewer. You could do this in ArticleHtmlWebEngineWriter::begin() by replacing:
  mWebView->load(QUrl());
with
  mWebView->load(QUrl(QStringLiteral("about:blank")));

(In reply to Patrick from comment #2)
> I did some debugging and found that the scroll position is remembered by the
> chromium backend used by Qt. The scroll position restore used by
> akregator/messagelib isn't working because javascript is disabled.

it's wrong as it's execute in specific environment.
js is enabled as private => it's execute for sure.

>
> As
> enabling javascript might have side effects, a possible solution is loading
> a blank page before a new article is loaded in the viewer. You could do this
> in ArticleHtmlWebEngineWriter::begin() by replacing:
>   mWebView->load(QUrl());
> with
>   mWebView->load(QUrl(QStringLiteral("about:blank")));

????

(In reply to Laurent Montel from comment #3)
> (In reply to Patrick from comment #2)
> > I did some debugging and found that the scroll position is remembered by the
> > chromium backend used by Qt. The scroll position restore used by
> > akregator/messagelib isn't working because javascript is disabled.
> 
> it's wrong as it's execute in specific environment.
> js is enabled as private => it's execute for sure.
> 
Javascript is enabled for external URLs, loaded in a new tab. But javascript is disabled for article content stored inside the feed, shown next to the article list (in widescreen view) or below the article list (in normal view). See the constructor of ArticleViewerWebEnginePage.


> >
> > As
> > enabling javascript might have side effects, a possible solution is loading
> > a blank page before a new article is loaded in the viewer. You could do this
> > in ArticleHtmlWebEngineWriter::begin() by replacing:
> >   mWebView->load(QUrl());
> > with
> >   mWebView->load(QUrl(QStringLiteral("about:blank")));
> 
> ????

The idea was to clear the page and reset the scroll position to the top, but it doesn't work well with the rest of the code.

(In reply to Patrick from comment #4)
> (In reply to Laurent Montel from comment #3)
> > (In reply to Patrick from comment #2)
> > > I did some debugging and found that the scroll position is remembered by the
> > > chromium backend used by Qt. The scroll position restore used by
> > > akregator/messagelib isn't working because javascript is disabled.
> > 
> > it's wrong as it's execute in specific environment.
> > js is enabled as private => it's execute for sure.
> > 
> Javascript is enabled for external URLs, loaded in a new tab. But javascript
> is disabled for article content stored inside the feed, shown next to the
> article list (in widescreen view) or below the article list (in normal
> view). See the constructor of ArticleViewerWebEnginePage.

I know as I implemented it :)
but we can call javascript even if it's disabled it as we execute it in specific "room". For sure as it works as it in kmail (coded that I implemented too)

> 
> 
> > >
> > > As
> > > enabling javascript might have side effects, a possible solution is loading
> > > a blank page before a new article is loaded in the viewer. You could do this
> > > in ArticleHtmlWebEngineWriter::begin() by replacing:
> > >   mWebView->load(QUrl());
> > > with
> > >   mWebView->load(QUrl(QStringLiteral("about:blank")));
> > 
> > ????
> 
> The idea was to clear the page and reset the scroll position to the top, but
> it doesn't work well with the rest of the code.

To clarify my case, I'll add some steps to reproduce the problem:

1. Select an article in the article list. Make sure the article is long enough for the vertical scrollbar to appear in the article viewer.
2. In the article viewer, scroll down to the bottom of the article.
3. Select another article in the article list. Again, make sure the article is long enough for the vertical scrollbar to appear in the article viewer.

Notice the scroll position after step 3. It's not at the top where you would expect it to be.

I confirm this bug. Version 5.5.3 on Kubuntu.

*** Bug 388690 has been marked as a duplicate of this bug. ***

Fix as per comment#2 submitted by https://phabricator.kde.org/D11385

Git commit 84b4da183fb85c752cccf10a7b0378477ae5be44 by Jonathan Marten, on behalf of Patrick NoSurname.
Committed on 24/03/2018 at 15:10.
Pushed by marten into branch 'master'.

Article viewer: Reset scroll position when loading a new article

In theory this should not be necessary as the article is scrolled
to the top via JavaScript, but this does not appear to work in
some reported cases.

Differential Revision: https://phabricator.kde.org/D11385

M  +1    -1    src/articleviewer-ng/webengine/articlehtmlwebenginewriter.cpp

https://commits.kde.org/akregator/84b4da183fb85c752cccf10a7b0378477ae5be44