Homesite: embedded Mozilla preview steals focus from editor pane

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
16 years ago
7 years ago

People

(Reporter: bugzilla.mozilla.org, Assigned: adamlock)

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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.
(Assignee)

Comment 1

16 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

16 years ago
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
(Assignee)

Comment 3

16 years ago
Reporter, are you saying the problem has gone away?
(Reporter)

Comment 4

16 years ago
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

15 years ago
FYI: This same bug affects the Mozilla preview inside TopStyle

Comment 6

15 years ago
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

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

Comment 8

15 years ago
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.
Assignee: adamlock → mirzmaster

Comment 9

15 years ago
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

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

Comment 11

15 years ago
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

14 years ago
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

14 years ago
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

14 years ago
(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

14 years ago
(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.

Updated

14 years ago
Assignee: mirzmaster → adamlock

Comment 16

12 years ago
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

12 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
Component: Embedding: ActiveX Wrapper → Embedding: ActiveX Wrapper
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.