131805 - can't debug when running an opt mozila build!

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect, P1)

Description

[Doug Turner (:dougt)]

Okay this totally sucks.  I am running 0.99 and I cant debug a trunk build. 
This DDE stuff has to be optional based on some env.

Comment 1

[Doug Turner (:dougt)]

Attachment: patch v.1

set MOZ_NO_DDE_SERVER before you run mozilla and the run will ignore the DDE
server.

Comment 2

[Darin Fisher]

Comment on attachment 74789 [details] [diff] [review]
patch v.1

r=darin (thank you!)

Comment 3

[Bill Law]

What exactly do you want this to do?  The patch not only turns off the "dde
server" but it also blocks creation of the MessageWindow, which maybe you didn't
intend.

Anyways, provided you're happy with that restriction, then I'd just suggest
changing the env variable name to something more generic, like
"MOZ_RUN_STANDALONE" or some such.  "MOZ_NO_DDE_SERVER" would seem to me to
apply just to the "this->StartDDE();" line slightly further down.  You're not so
much disabling the DDE server as you are ignoring an already running instance of
Mozilla (i.e., an already existing MessageWindow, which I think is
implementation detail to most folks).

Comment 4

[Doug Turner (:dougt)]

I didn't want the var name generic, or at least I wanted it windows specific.

Comment 5

[Bill Law]

But my point is that you don't give a flip about the DDE server.  We don't use
DDE to communicate between new instances of mozilla.exe and already running
ones, so it seems odd to name the environment variable "MOZ_NO_DDE_SERVER."

Isn't this Windows-centric enough already (it is only used in this one
win32-only module)?

Comment 6

[Doug Turner (:dougt)]

MOZ_NO_DDE ?

Comment 7

[Bill Law]

Hmmm, seems I'm having trouble making myself understood.  Let me try again.

There is only 1 line of code that has *anything* to do with DDE.  That's the
call to StartDDE().

If we just up and remove that call, you still have your problem (starting a
second Mozilla just sends a message to the first).  If we move that call ahead
of your check for MOZ_NO_DDE_SERVER, then you'd still get what you want when you
specify MOZ_NO_DDE_SERVER.  Ergo, the problem has *nothing* to do with DDE.

It isn't a DDE issue.  It's a *message window* issue.

Now your patch happens to turn off the DDE server when it detects
MOZ_NO_DDE_SERVER, but that's just coincidence.  It also turns off the -turbo
mode systray icon.  But there's no way we'd name the environment variable
"MOZ_NO_SYSTRAY_ICON."  I'm just saying we shouldn't name it MOZ_NO_DDE_SERVER,
either, for the same reason.

Comment 8

[Doug Turner (:dougt)]

darin, dan, any name suggestions?

Comment 9

[Darin Fisher]

i defer to law, conrad (or anyone else)... i'm out of my element here ;-)

Comment 10

[Doug Turner (:dougt)]

MOZ_NO_REMOTE  <- similar to xremote

Comment 11

[Bill Law]

That's fine.  No normal user would likely make the connnection, but it's not for
them anyway.

Comment 12

[Doug Turner (:dougt)]

Attachment: patch v.2

changes the name of the env var.

Comment 13

[Doug Turner (:dougt)]

Comment on attachment 75655 [details] [diff] [review]
patch v.2

carrying forward r= from darin.

Comment 14

[Gagan]

per dougt this helps for a lot of other topembed bugs. So a plus.

Comment 15

[Alec Flett]

Comment on attachment 75655 [details] [diff] [review]
patch v.2

sr=alecf

Comment 16

[Asa Dotzler [:asa]]

Comment on attachment 75655 [details] [diff] [review]
patch v.2

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 17

[Doug Turner (:dougt)]

Checking in nsNativeAppSupportWin.cpp;
/cvsroot/mozilla/xpfe/bootstrap/nsNativeAppSupportWin.cpp,v  <-- 
nsNativeAppSupportWin.cpp
new revision: 1.63; previous revision: 1.62
done

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 19

[Alfonso Martinez]

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