Bug 115922 - [testcase] focus javascript method called on a specified element after "Back" does not work
Summary: [testcase] focus javascript method called on a specified element after "Back"...
Status: RESOLVED WORKSFORME
Alias: None
Product: konqueror
Classification: Applications
Component: khtml event (show other bugs)
Version: 4.0.3
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2005-11-08 14:56 UTC by Enrico Oltolina
Modified: 2018-10-27 04:05 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Enrico Oltolina 2005-11-08 14:56:13 UTC
Version:           Konqueror 3.4.2 (using KDE KDE 3.4.2)
Installed from:    SuSE RPMs
OS:                Linux

Two html pages, in first one there is a onLoad event handler in body. The called function when the Load event is generated retrieve an element by an Id and then it sets the focus on it. This works! Second step: click on a link and go to the second page. Third step: press the "Back" command on konqueror toolbar in order to return to the first page. When loaded the first page, the onLoad function is called, but the focus does not work.
It's possible to test this case using the following html code:
File onLoadTest.html

<html>
<head>
<script>
  function start()
  {
    alert("ON LOAD");
    document.getElementById("2-1").focus();
  }
</script>   
</head>
<body onLoad="start()">
  <blockquote>
    <h2>BACK TEST: PAGE 1</h2>
    <BR><BR>
    <a href="page01.html" id="1-1">LINK 1</a>
    <br>
    <a href="page01.html" id="2-1">LINK 2</a>
    <br>
    <a href="page01.html" id="3-1">LINK 3</a>
    <br>  
  </blockquote>
</body>
</html>


File page01.html

<html>
 <head>
 </head>
 <body>
   <BR>PAGE 01</BR>
 </body>
</html>


When loading the first page, the focus is on the second link. Clicking on the third one, and then press back: the focus is on the third link, while expecting always on the second.
I tried this simple test also with firefox and Explorer, and the test works (link on second element).
Comment 1 Enrico Oltolina 2005-11-08 18:00:53 UTC
Maybe the problem is in the KHTMLPart::slotFinishedParsing() method: 

void KHTMLPart::slotFinishedParsing()
{
  d->m_doc->setParsing(false);

  checkEmitLoadEvent();
 disconnect(d->m_doc,SIGNAL(finishedParsing()),this,SLOT(slotFinishedParsing()));

  if (!d->m_view)
    return; // We are probably being destructed.

  checkCompleted();
}

First, the LOAD signal is emitted (and so the onLoad event handler function is executed), after that the checkCompleted function is executed. The checkCompleted, as first step, restores the cursor position. So, the onLoad set the focus, and the checkCompleted restore the original position. 
I tried to modify the slotFinishedParsing() in the following way:


void KHTMLPart::slotFinishedParsing()
{
  d->m_doc->setParsing(false);

  // restore the cursor position
  if (d->m_doc && !d->m_doc->parsing() && !d->m_focusNodeRestored)
  {
      if (d->m_focusNodeNumber >= 0)
          d->m_doc->setFocusNode(d->m_doc->nodeWithAbsIndex(d->m_focusNodeNumber));

      d->m_focusNodeRestored = true;
  }

  checkEmitLoadEvent();
  disconnect(d->m_doc,SIGNAL(finishedParsing()),this,SLOT(slotFinishedParsing()));

  if (!d->m_view)
    return; // We are probably being destructed.

  checkCompleted();
}


and now it seems that konqueror works well.
I know that this is not a definitive solution, maybe it could be enough to execute checkComplete and after that checkEmitLoadEvent, but I don't know if there are some side effects.

Comment 2 Enrico Oltolina 2005-11-17 12:09:05 UTC
Ok, my previous patch does not work!
I changed the code in KHTMLPart::checkCompleted() in the following way:

  DOM::NodeImpl* firstFocus = NULL;
  DOM::DocumentImpl* document = xmlDocImpl() ;
  if (document) {
    firstFocus = document->focusNode();
  }
  if (d->m_doc && !d->m_doc->parsing() && !d->m_focusNodeRestored) 
  {
      if (d->m_focusNodeNumber >= 0 && firstFocus == NULL)
          d->m_doc->setFocusNode(d->m_doc->nodeWithAbsIndex(d->m_focusNodeNumber));

      d->m_focusNodeRestored = true;
  }


I hope this works well...

Comment 3 Philip Rodrigues 2006-09-07 21:37:21 UTC
I can confirm the behaviour described (3.5 branch r575787), but perhaps it's deliberate? (user's focus chosen by clicking on a link overrides the focus set by the JS). I'll mark confirmed so the developers can take a look
Comment 4 James Spahlinger 2008-04-19 21:40:33 UTC
This still happens in 4.0.3

Steps to reproduce are listed in the first entry, I'll copy paste for ease:
>When loading the first page, the focus is on the second link. Clicking on the third one, and then press back: the focus is on the third link, while expecting always on the second.

The first page can be found at http://nixeagle.org/kdebugs/115922/onLoadTest.html the "focus" should be on the middle link in the list. Click ok on that javascript popup, click the 3rd link (last one in the list). It will load page01.html on the same server. When it loads, click back. Click ok on the popup again. At this point, the focus should be on the middle link, instead its on the last link. (the one you just clicked).


Using Gentoo Linux ~x86 (testing in gentoo lingo). KDE and the majority of packages compiled using gcc 4.3.0. 
Comment 5 Janek Bevendorff 2012-06-22 14:45:17 UTC
There hasn't been any activity on this report for some time. Please check if the issue is still valid for Konqueror 4.8.4 or later. Thank you.
Comment 6 Andrew Crouthamel 2018-09-23 02:36:05 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 7 Andrew Crouthamel 2018-10-27 04:05:44 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!