203058 - Homesite: embedded Mozilla preview steals focus from editor pane

Status: RESOLVED WORKSFORME

(Core Graveyard :: Embedding: ActiveX Wrapper, defect)

Description

[bugzilla.mozilla.org]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030418
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030418

I'm not quite sure when this startet, it might be relatet to the time when
type-ahead-find got activated by default in nightlies ...

I use Macromedia Homesite as HTML Editor on Windows. There you can use mozilla
(or IE) as embedded previewer: So the editor window gets splittet in an editor
part and an mozilla-preview part. You can type our code in the editor and when
you stop typing Homesite automagically saves a temp copy of the file and
refreshes the preview to show this temp version of the file to edit. 

Now, with the current builds the following happens:
If ou stop typing in the editor the preview gets refreshed and the embedded
mizilla steals the keyboard focus from the editor. you have to click in the
editor pane to be able to type in there again. But next refresh the focus os
gone again - very annoing.

this did not happen with older mozilla builds. with the old ones I could
continue typing, the preview got refreshed from time to time but without
stealing the focus.

I think this might be related to the type-ahead-find.

Question: is there a pref to turn this focus stealing off completely?

user_pref("accessibility.typeaheadfind", false) stops the searching but still
steals focus

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Adam Lock]

CC Aaron & Chris

I'll confirm this as new as it sounds likely though I don't have Homesite to
test. It seems odd that loading a page would steal keyboard focus.

Comment 2

[bugzilla.mozilla.org]

One more hint:

I tried it now with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1)
Gecko/20030418

no focus stealing, the embedded mozilla control behaves nice

Comment 3

[Adam Lock]

Reporter, are you saying the problem has gone away?

Comment 4

[bugzilla.mozilla.org]

no!!!!

it's not gone away. It still happens in the 1.4x series.


I just wanted to confirm that 1.3.1 does not have this but.

Comment 5

[Nick Bradbury]

FYI: This same bug affects the Mozilla preview inside TopStyle

Comment 6

[Neal Laugman]

In Homesite 5.2+ and in Topstyle 3.10 - this was not the case with Moz 1.3 but 
the bug is in 1.4 and 1.5

Comment 7

[Sohail Mirza]

When can we expect this bug to be assigned?  Is it considered to be a bug with
any amount of priority?

Comment 8

[timeless]

i can assign the bug to you today, and tomorrow you can tell us what priority it
has for you and when you expect to fix it.

Comment 9

[Sohail Mirza]

Cool!  My very first bug!  Now if only I was a hardcore hacker and knew where to
start in diagnosing and resolving the problem  ;)

hehe... sorry timeless, I was just asking a couple of innocent questions...
didn't expect to have the bug assigned to me!  :S  Any other takers?

Comment 10

[Bryan]

I have a similar problem when using Mozilla as my internal preview browser with
TopStyle Pro 3.x

Comment 11

[Tim Danner]

This does not appear to be specific to TopStyle or HomeSite. It also occurs in
SharpReader and a simple test app that I wrote. This was with the current
(1.7.1) version of the control.

Comment 12

[irongut]

This is not unique to HomeSite or TopStyle, I can reproduce it in a Delphi app
using v1.7.1 of the control. I have a workaround for Delphi, unfortunately not
much use for HomeSite/TopStyle users.

Problem: If I type in an edit box and press enter my app navigates to the url I
typed and the embedded control steals focus from my edit box.

Workaround: My embedded control sits on top of a panel. If I disable the panel
before navigating to the url and then re-enable it when finished the control
doesn't steal the focus.

Comment 13

[Anthony Steele]

I have much the same bug in a delphi program that uses the 1.7 control. A demo 
that reporoduces the bug is given below.  Output from the demo program is as
follows:

Settting focus to the memo and then clicking button btnTest causes the message
'Focus gone' to appear, since clicking on the button moves focus off the memo.

Settting focus to the memo and then clicking button btnSetAndTest does nothing -
focus returns to the memo, you see a flashing vertical bar text cursor there,
and if you type, the memo gets the text.

Settting focus to the memo and then clicking button btnSetLoadAndTest causes odd
behavior: Focus should be on the meo, and the message is not displayed, so
delphi thinks that the memo still has focus. However the memo no longer has a
flashing vertical bar text cursor, and no longer accepts text. 

I've had more than one person report this as a bug in my chat program, and it's
quite annoying, since the upshot is that while they are typing a message, the
chat view refreshes on a timer, and this causes the keypresses that they are
banging out to randomly get ignored. Or treated as hotkeys when the form gets them. 

I suspect that this is something to do with how the activeX control wrapper is
coded.

Demo code in delphi 7:


unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, OleCtrls, MOZILLACONTROLLib_TLB;

type
  TForm1 = class(TForm)
    Memo1: TMemo;
    btnSetAndTest: TButton;
    btnTest: TButton;
    MozillaBrowser1: TMozillaBrowser;
    btnSetLoadAndTest: TButton;
    procedure btnSetAndTestClick(Sender: TObject);
    procedure btnTestClick(Sender: TObject);
    procedure btnSetLoadAndTestClick(Sender: TObject);
  private
    procedure TestFocus;
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.btnSetAndTestClick(Sender: TObject);
begin
  Memo1.SetFocus;

  TestFocus;
end;

procedure TForm1.TestFocus;
var
  lcTest: TControl;
begin
  lcTest := ActiveControl;
  if (lcTest <> Memo1) then
    ShowMessage('Focus gone');

end;

procedure TForm1.btnTestClick(Sender: TObject);
begin
  TestFocus;
end;

procedure TForm1.btnSetLoadAndTestClick(Sender: TObject);
begin
  Memo1.SetFocus;

  MozillaBrowser1.Navigate('file://c:/test.html');

  TestFocus;

end;

end.


and the dfm file:

object Form1: TForm1
  Left = 278
  Top = 278
  Width = 691
  Height = 439
  Caption = 'Form1'
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'MS Sans Serif'
  Font.Style = []
  OldCreateOrder = False
  PixelsPerInch = 96
  TextHeight = 13
  object Memo1: TMemo
    Left = 20
    Top = 20
    Width = 185
    Height = 89
    Lines.Strings = (
      'Memo1')
    TabOrder = 0
  end
  object btnSetAndTest: TButton
    Left = 56
    Top = 176
    Width = 100
    Height = 25
    Caption = 'Set and test'
    TabOrder = 1
    OnClick = btnSetAndTestClick
  end
  object btnTest: TButton
    Left = 56
    Top = 140
    Width = 100
    Height = 25
    Caption = 'Test'
    TabOrder = 2
    OnClick = btnTestClick
  end
  object MozillaBrowser1: TMozillaBrowser
    Left = 304
    Top = 100
    Width = 192
    Height = 192
    TabOrder = 3
    ControlData = {00070000D8130000D8130000}
  end
  object btnSetLoadAndTest: TButton
    Left = 52
    Top = 212
    Width = 100
    Height = 25
    Caption = 'Set, Load and test'
    TabOrder = 4
    OnClick = btnSetLoadAndTestClick
  end
end

Comment 14

[irongut]

(In reply to comment #13)

I have a Delphi workaround for this problem, contact me by email and I'll send
you the code.

Comment 15

[Anthony Steele]

(In reply to comment #14)


Irongut's workaround to this bug is as follows:

Put the mozilla controls on a TPanel, in this e.g. called pnlBrowser.

Load the browser control like this:

procedure TForm1.btnSetLoadAndTestClick(Sender: TObject);
begin
  Memo1.SetFocus;

  { disable the panel }
  pnlBrowser.Enabled := False;
  MozillaBrowser1.Navigate('file://c:/test.html');

  TestFocus;
end;


Then you'll need an app events with an idle handler, to reenable the panel like 

so:

procedure TForm1.ApplicationEvents1Idle(Sender: TObject;
  var Done: Boolean);
begin
  {re-enable panel when navigate complete so edt keeps focus}
  if not(pnlBrowser.Enabled) and not(MozillaBrowser1.Busy) then
    pnlBrowser.Enabled := true;

end;


The good news is that in a more complex program, this concept appears to work
well too.

Comment 16

[Wayne Mery (:wsmwk)]

do you still see this problem? 

to those who I just cc:, you need to cc yourself when you comment in a bug if you want to see future responses and resolutions. (unless you voted and turned on bugmail for voted bugs)

Comment 17

[Wayne Mery (:wsmwk)]

Bryan Hoff wrote on 1/26/2007 "I just tested it and it appears to be fixed." so I am closing WFM. Please reopen the bug if you still see it.