Closed Bug 29952 Opened 25 years ago Closed 24 years ago

chrome buttons (reload, stop) don't reflect finger loading

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jruderman, Assigned: bryner)

References

(
URL
)

Details

(Keywords: testcase) 

Mozilla leaves the "stop" button disabled and the "reload" button enabled while 
loading a finger.

Related: bug 29457, finger doesn't show "document done" on complete

(PS thanks for implimenting finger:)
Confirmed with the 2000-03-06-08-M15 nightly binary on WinNT.
While the status bar says "Transferring data from..." and before the data is
displayed the Reload and Stop buttons remain unchanged.
Assignee: cbegle → bryner
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
QA Contact: asadotzler → tever
Summary: chrome buttons (reload, stop) don't reflect finger → chrome buttons (reload, stop) don't reflect finger loading
This looks really similar to (in fact maybe a dupplicate of) bug 29457. 
valeski, what do you think?
Status: NEW → ASSIGNED
This depends on progress event sink stuff, which I'm currently trying to figure
out.
OS: Windows 98 → All
Target Milestone: M15
Checked in fix.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Not quite right yet.  If you use the forward button to go to a finger: URL, the 
forward button becomes both disabled and depressed.  This effect goes away if 
you alt-tab to another application that covers the area.  (tried only on Win32)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Is there a spec that describes how the chrome buttons are supposed to behave?  
If there is one, it would be helpful in getting the chrome buttons to work 
similarly on all types of URLs.
That sounds like more of a painting problem than anything... but you're saying 
this only happens for finger: url's?

Oops, that happens everywhere.
In that case, I'd suggest filing a new bug on that, maybe on XPToolkit/Widgets.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Okay, filed bug 33144 and bug 33145 on the toolbar button messiness.
Verif fixed 2000 093008 Win98.
The toolbar buttons now act consitstently for the finger and http protocols.
Status: RESOLVED → VERIFIED
->xp apps
Component: Networking → XP Apps
+testcase.
Finger is a small protocol, so I took them under the necko tests for finger.
Keywords: testcase
transferring these to my netscape.com email.
Assignee: bryner → bryner
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.